基本情報

・日時場所: 2019-07-08(Mon) 19:00-21:00 @TECH PLAY SHIBUYA
・ホーム: https://techplay.jp/event/734673
・Twitterハッシュタグ:https://twitter.com/hashtag/TechOn東京
・togetter: https://togetter.com/li/1374311
・概要: 「DevOps」の中でもより「Ops」にフォーカスを当て，Ops視点でのDevとの関わり方や，Opsの課題を技術やプロセスで解決する取り組みについて登壇者にお話いただく
・タイムテーブル
　　・オープニング (19:00-19:10)
　　・セッション (19:10-20:10)
　　　　・Ops meets NoOps ～そのとき何が起こったか～ (日本マイクロソフト株式会社 真壁 徹)
　　　　・チーム開発におけるDevとOpsのプラクティス (KDDI株式会社 廣田 翼)
　　・ライトニングトーク会 (20:20-20:50)
　　　　・SRE はじめの一歩 (株式会社JX通信社 平瀬 達也(たっち))
　　　　・Slackによるインシデント対応 (コネヒト株式会社 金城秀樹)
　　　　・MLOps (日本マイクロソフト株式会社 中村 憲一郎)
　　　　・Microservice x ScrumなBtoB_Webアプリケーション開発現場のOps話 (CyberAgent 小西 宏樹)
　　　　・ZOZOTOWNを支えるチーム運用について (ZOZOテクノロジーズ 鶴見 純一)​
　　・クロージング (20:50-21:00)​

サマリ・所感

　以下のように，既に詳細な参加レポートが幾つかネットで共有されていた (こういう情報共有の早さと精神がMeetUpのいいところ！)ので，この参加メモではまとめと感想だけ書きます (手抜き)。
・https://note.mu/suwash/n/nb9554de8a610
・https://qiita.com/taumax/items/a1f9572fe38d41011fd8

DevOpsはツール以前に組織文化

　分かってはいたが，MSの真壁氏の話を聴いてよりこの思いを強くした。氏の感覚では，DevOps/NoOps (システム運用の嬉しくないことをなくす，人が要らないではなくやらなくていいことをなくす)に乗り出す組織は多いのだがなかなかギアが上がらない，特に歴史のある企業では1速にも入らないことも多いそうだ (先に組織だけができて，その後標準・ガイドラインづくりとか…)。特に心に残ったのは，「今やっていることを『やめよう』と胸を張って言える組織ですか？」という問いかけ。「作ることは誰にでもできる。難しいのは偉い人が『やめる判断』をするところ。作ることばかり話す偉い人は危険。」とか…。

　ではどうすればDevOpsを軌道に乗せられるか，という話に繋がるわけだが，少数のコアメンバーだけでも良いので，まず意欲のある人を集めてチームを作ることから始めると良いとのこと。大事なのは能力よりも成長思考であり，小さくてもいいから，自分達で手を動かして実績 (ちょっとでも運用をラクにするツールとか)を作ることが大事。

Observabilityと，Chaos Engineering/継続的障害訓練

　DevOps/NoOpsに着手するガイドラインとして，Cloud Native Trail Mapの紹介があったが，真壁氏によると「1. Containerization」ではなく「4. Observability & Analysis」から始めると良いとのこと。「Observability (可観測性)」は制御工学の専門用語だが，まさかCloud Nativeの世界で大昔に学んだ制御工学の言葉が出てくるとは思わなかった。真壁氏は「今日は『監視システムをOpsの道場にする！NoOpsのコンセプトで作ってみる。』を言いたくて渋谷に来た」そうで，そのために「可観測性」という考え方が今後ますます重要になるだろうという考えを示した。NetflixのChaos Engineering基盤であるChAPで，本番トラフィックの5%まではChaosMonkey (故意/自動的に障害を発生させるシステム)を動かし続けて，システムの回復性を鍛えている事例を紹介し，これはシステムをきっちり観測しているからこそなせる業であることを強調していた。

　次の登壇者の廣田氏も，「継続的障害訓練のススメ」で「Chaos Engineering」に触れていた。Netflixとは異なり，本番と同じステージング環境で継続的に障害を訓練する (運用担当者には事前に障害の内容を教えない)という事例だが，これを通じてシステムや運用スキームの弱点の把握と対策ができたという成果があったそうだ。

　恥ずかしながら，「Chaos Engineering」も「継続的障害訓練」も初耳だったが，今後サービスビジネスの企画・開発・運用に関わっていく自分にとっては，非常に重要な考え方だと直感した。

参考​

・セッション及びLT中に紹介のあった参考資料へのリンク。
　　・NoOps?よろしいならば戦争だ
　　・NoOps Definition
　　・Cloud Native Trail Map
　　・Chaos Engineering