1.はじめに

2022/04/21(木)と22(金)に開催された、DevOpsDays Tokyo 2022にリモート参加したので参加レポートを書いた。現地参加もできたのだけど開催場所から自宅までが結構遠いのでZoom + Discord で参加した。何分不自由なく参加できたけど、強いて言えば、今半弁当を食べることができなかったのは悔やまれますね笑

https://devopsdays.org/events/2022-tokyo

2.聞いたセッション

3.印象に残ったフレーズや一言感想

3-1.価値あるソフトウェアをすばやく届けるために僕らがやってきたこと 〜経営者による組織とカルチャー作り〜

印象に残ったフレーズ

一言感想

  • 印象に残ったフレーズが多々あるけれど、感想として自分の考えも残すとしたら、「評価と査定の分離」の話
  • ブログを書くことは評価にはつながらず、ブログを書くことで結果的に仕事もできるようになり、巡り巡って評価につながる。日の目を見ない期間が多い印象はたしかにある。
  • ブログにかぎらず、日々の活動のモチベーションの厳選をおカネや評価にといった外発的なものではなく内発的にできるかどうか？が大事だと感じた。

3-2.ファクトから始めるカイゼンアプローチ ～「LeanとDevOpsの科学」を実践して～

一言感想

3-3.作る人から作りながら運用する人になっていく

一言感想

  • How SRE Relates to DevOps
  • テストピラミッドとコンシューマ駆動契約という考え方を知った
  • 改めてセッションをふりかえると、開発主体から開発も運用もというスタンスの移行の建前として、組織全体で知見を獲得したいといった「取り組みの成否にかぎらない」大義が用意されていると、比較的新しい取り組みの一歩を踏み出しやすいのかもしれないと感じた。また、実行部隊の規模が大きくなるとそういった大義を掲げることも難しいはずとも。

3-4.コンプライアンス対応をチームの力に ~ 監査人が考える今後のDevOps

一言感想

  • 監査チームのような、開発、運用業務をしているとあまり接点がすくなりがちな方々と日頃から意見を交わすことは大事。とはいえ、意見交換しようとなるのも難しく感じてしまう笑
  • ChatOpsいいね！という監査の方から見た意見が印象的。「このチャンネルを見れば余計なことはしていないとわかるんです。」と言えるのがChatOpsのいいところとのこと。
  • 他に印象に残ったところは、デプロイメントパイプラインの権限整理とコンプラ対応を設計する上で競合他社を反面教師とするというところ

3-5.レガシーなシステムをリプレースした後に起きた開発組織の変化について

印象に残ったフレーズ

  • お伺いマラソン
    • このセッションは、お伺いマラソンに形容される、相互依存でありモノリシックなレガシーアーキテクチャの移行前、移行前夜、移行後と時系列に分かれてお話されていて、とてもわかりやすかった。

一言感想

  • Python2系で作っていて、GCPが日本に展開する前からローンチしていたところからの移行。これだけでヤバそうということはわかる。
  • やらないことのひとつとして過度な分割＝いきなりマイクロサービスに分割しないというお話はリアルでどのくらいの塩梅で設計されたのか？気になる。技術ブログなどでの続報が楽しみ！
  • 似たような話として、Uber社のマイクロサービスからマクロサービスへの移行というお話があり
  • 開発組織が本当に欲しかったものは、「選択の自由」というフレーズにともて勇気づけられた。

    • 保守的だったのは開発組織ではなく、ルール。ルールを変えれば人は適応する。

3-6.CI/CDパイプラインにE2Eテストを統合する

一言感想

3-7.Chris Lucian: Interview with Q&A

一言感想

  • My turn to learn というより、ぼくはドライバーでもナビゲーターでも意見を聞く姿勢でやっているなと感じた。ドライバーであれば、手を動かすこともやるし、ナビゲーターであれば指示の他に作業ログを残すこともするけど、自分の意見に自信を持つことができないというのが影響しているのかな？と自己分析した。
  • モブプロのセッションはメンバー間に能力差がある場合、ナビゲーター、ドライバーの役割分担が固定化してしまうのでは？というやりとりが印象的

3-8.Flaky test対策の最新動向

一言感想

  • デプロイパイプラインのオオカミ少年化問題

    • Flaky Testにかぎらず、テストのエラー結果を誤検知(False-Positive)と判断するのはむずかしい。
    • というのも、テストというのは、その性格上、デプロイ前にバグを炙り出すセーフティネットの役割を担うことが多く、だからこそ「網に引っかかったら確認する」というのがセオリーだと思うので。

  • Flaky Test は減らすべきものというのが一般的だが、pre-merge 段階で発生した場合無視するという選択もあり

  • Meta社(旧Facebook社)の Bayesian inference など、テストの実行結果の成否とそこにいたるまでの変数を使ったモデルもある

※ そもそも Flaky Test という概念を知らなかったので以下の記事などを拝見しながら聞いていた

3-9.食べログのソフトウェアテスト自動化デザインパターン

一言感想

  • ログインの有無によって見せる画面が変わるというのは実装が大変そう（自分の経験でもたいへんだった。ボタンの活性化、非活性化などを Selenium で扱うことがあり、些細な UI の変更に追随するだけでもたいへんなのに。。）
  • CircleCI Insights を使っている👀

3-10.デプロイ頻度を高めるために私達にできることは一体何があるだろうか？

印象に残ったフレーズ

  • マージするよりも分離するほうが難しい
  • 重要なのはデプロイ頻度ではなく、小さい単位でデプロイすること
  • レビュアーが見つけやすい誤りを資料に用意しておき、リリース判定会議に臨む笑（レビュアーとレビュイーが仕事をしたことにするためのハック）
  • 既存のコードから類似処理をコピペし続けた結果、リファクタリングの範囲が爆増
  • デプロイがシンプルに怖い
  • 潜在的な（時限爆弾のような）バグ

※ 同セッションは、登壇者様の前前職のご経験を踏まえて構成されており、当時の様子は以下の書籍でも取り上げられているとのこと。

Engineers in VOYAGE

一言感想

  • 「デプロイがシンプルに怖い」がほんそれ！僕の場合は何回やっても慣れるとラクになる代物ではない。デプロイはニンゲンがやるものではない！
  • 「デプロイができる単位で小さくするためにできること」という観点でプログラムの設計やコミットの粒度ひとつひとつ考えねば

3-11.PagerDutyでシステムノイズを削減し、インシデントの解決を自動化する方法

一言感想

  • PagerDutyとは、監視アラートの集約ツール（そもそもなにか？というところから知らなかったので）
  • 運用当番、エスカレーションのローテーションの自動化やResponce Cost は集約しているからこそできる機能だと感じた。

3-12.Matthew Skelton / Alex Papadimoulis - Matthew Skelton: Interview with Q&A

印象に残ったフレーズ

  • チームデザインのデザインパターン、メタデザイン。

一言感想

4.さいごに

DevOpsDays Tokyo 2022 のスタッフ様、ならびに登壇者様、おつかれさまでした。たのしかったです！