2018/12/07 に開催された NoOps Meetup Tokyo #3 のイベントレポートです。

●イベント概要
NoOps = No "Uncomfortable" Ops

NoOps Japanでは 「システム運用保守の"嬉しくないこと"をなくそう！」 をテーマに、 NoOpsを実現するための技術・設計手法・開発運用保守サイクル・ツールや考え方・事例などを共有していきたいと考えています。

NoOps Meetup Tokyo では業界の第一人者のみなさんに登壇いただき、それぞれの視点でのNoOpsをお話いただきます。 また今回は、NoOps Meetup and OpenHack 企画ネタ応募LTを募集します。今後のNoOps Japanの活動で取り上げてほしいテーマをぜひアピールください！

■オープニング

岡 大勝 さん

●おさらい 10.26 NoOps Meetup Tokyo #2
・MicroserviceでのNoOps戦略
　　Yusuke Suzukiさん
・ITインフラのNoOpsを実現する戦略と方法論
　　Tomoaki Nakajimaさん
・なかなか楽にならない証明書の話
　　@shibayan さん

●Microsoft Tech Summit 2018
・僕らのNoOps 〜The Diversity of NoOps〜
　　動画が公開されている

●Japan Contaienr Days v18.12
・NoOpsが目指す未来とコンテナ技術
　　攻めのNoOps実現のための能力をupdate
　　Zero Trust Networkの有識者も登壇してもらいます！
　> イベントレポートはこちら

●共感駆動のSRCAサイクル
　　共感 > 尊重 > 貢献 > 感謝

■光り輝くTBD（仮）

西谷 圭介 さん

●Opsは悪なのか？
・Undifferentiated Heavy Lifting
　　付加価値を産まない作業
　　　　OSのセットアップ
　　　　認証認可処理
　　多いとビジネスロジックに集中できなくなる
　　これを減らしたい

・プロダクトを差別化するのはソフトウェア
　　いわゆるビジネスロジックを実装する時間をつくろう

・そうだ コード、書こう
　　環境を整えよう
　　開発環境だけでなく、働く環境

●Amazonのはなし
　　モノリスだった > Microservices / DevOps
　　組織と切り離せない > Two pizza team

・Two Pizza Teams
　　組織が大きくなると、分割している
　　作るものに対する全てを追う
　　大きな組織の一部分
　　you build it, you run it

・全部ってどこまで？
　　QA、オンコールも
　　では Opsは何をしている？ > いない
　　　　SRE？ > いない
　　各チームに必要な役割が揃っている

・高い水準を維持する必要が出てくる
　　チームに権限が与えられ、多くの自由が認められる
　　　　開発プロセス、採用
　　　　オンボーディング/トレーニング
　　あらゆるスケールで定義されたパターン/プラクティス、ナレッジ
　　定期的に技術的、ビジネス的なメトリクスレビュー
　　定期的に新ツール、サービス、技術の共有
　　Our Leadership Principles(OLP)

●OLP
・採用もOLPに沿って
　　人によってチェックする項目が変わる

・Customer Obsession
　　他のOLPは、これには勝てない

・Ownership
　　DevOpsにはココが関わってくる
　　長期的な視点が必要
　　Automate Everything!
　　テストしやすいようにアーキテクチャをデザインする
　　運用もAutomate Everything!
　　Two Pizza Teamなので人手が足りない >NoOps!

・Dive Deep / Learn and Be Curious
・Frugality
・Think Big

・Bias for Action
　　早く失敗して良いものに育てていく

・Hire and Develop the Best
　　困っているから採用のバーを下げてしまいがち
　　採用のインタビューチームに、チームと直接利害関係がない人が入る
　　チームの平均値を上げる人しか採用しない

・Have Backbone; Disagree and Commit
　　データドリブンで、経緯を持って意義
　　決まったら全力でコミット

・Invent and Simplify
・Are Right, A Lot / Earn Trust

・Insist on the Highest Standard
　　常に高い水準を目指した、ピアレビューが日々行われている

・Deliver Results
　　最初がCustomer Obsession
　　最後がDeliver Results
　　これは変わらない

　　重要なことにフォーカス
　　　　溜め込まずイテレーションを回す
　　　　MVPで、お客様と一緒に育てていく
　　　　自動車だと
　　　　　　スケボー > キックボード > 自転車 > バイク > 自動車

運用ゼロは幻想 > LessOpsはできる
サーバーレスっていうのがあるよ↓

■Serverless の自動化と自動回復のためのアーキテクチャ

牛尾 剛 さん

●NoOpsに取り組むための最初の一歩を始めてほしい
・サーバーレスは最初にちょうどよいね
・テストはしにくいよね
　　Event
　　Trigger
　　InputBindings
　　CODE
　　OutputBindings
・すぐ作れるから、だいたいテストをサボっちゃう

●翻訳めんどくさい
　　Markdown Translator
　　Durable Functions 使ってる

●自動化のアーキテクチャ
・ユニットテスト
　　テストピラミッド
　　　　Unit Testing: 80%
　　　　Integration Testing
　　　　E2E
　　　　　　ハッピーパスくらいに抑えて良いのでは？
　　重要性
　　　　これなしでCI/CDは意味がない
　　　　自身を持てる
　　　　テストがないコードは存在しないのも同じ
　　　　良いアーキテクチャにつながる

・良いユニットテスト
　　リグレッションエラーを検出
　　false positiveの割合が少ない
　　　　mockのせいで落ちるべきところが通っちゃう
　　10分以内！
　　メンテコストが低い
　　simple

・Hexagonal Architecture
　　コラボレータとの接点をmockに
　　DDD！
　　Fixture Object Pattern

・DI and Wrapper
　　クラスに対してInterfaceを用意しよう
　　　　golangですら、用意してあるしね
　　Interfaceがない時は、Wrapperで

・テスト可能な設計のためのtips
　　Domain Object
　　コラボレータとの接点をmock
　　bindingsを使う
　　単一責務の法則
　　Interfaceを導入
　　Wrapper
　　リポジトリパターン

・回復性の設計の肝
　　リトライさせたい単位で作るべき > 単一責務

・自動回復のためのアーキテクチャまとめ
　　単一責務の法則
　　冪等性
　　リトライ単位での関数

●分散トレーシング
※分散トレーシング、やってみると地獄w
・プロトコル
　　Http Correlation Protocol
　　W3C Trace Context ※これからはこっち

・マニアックな記事3部作

・実装の課題
　　プロコルがHTTP前提
　　コールコンテキストが異なる場合、引き継げない
　　トレースコンテキストの引き渡し
　　トレースステートのリストア
　　関連サービスをまとめて対応しないといけない
　　途切れると役に立たない
　　実装は黒魔術だらけ

NoOpsに向けて一歩を踏み出そう！
シアトルで支部やります！

■公募LT1「今後のNoOpsJapanの活動で採り上げてほしいネタ（仮）」

@changeworlds さん

■公募LT2「まだToilで消耗してるの？」

@nntsugu さん

「回復性」のレベルは後から変更できない
どうしてもToilを生みがち
小さい組織だとなかなか効率よく改善できない
NDAだけ結んで、ギャップを埋める活動やってみませんか？

■公募LT3「一人から始める hackfest! ～ OSS コミットへの最初の一歩」

@dz_ さん

■公募LT4「DevOpsとそのちょっと外側とNoOps」

@amemolee さん

プレスリリースから始めよ
DevとOpsを省力化して、外側のプレスリリースに力をかけてみよう

■感想

・西谷さん
two pizza team、OLPの話は、聞くたびに自分の状況に応じて別の学びをもらっている気がします。The Agile Guildの活動をはじめた、現在だとこちら

・あらゆるスケールで定義されたパターン/プラクティス、ナレッジ
・定期的に技術的、ビジネス的なメトリクスレビュー
・定期的に新ツール、サービス、技術の共有

多数の小さなチームができるから、各チーム、全体どちらの成長も進めるために
　・チームの学びを整理して共有
　・チームを定量的に評価
　・チームの成果を共有
を定期的に実施する流れが生まれたのが、実感として感じ取れました。
評価するに必要な基準も、OLPをベースに考えられているのだろうな、と想像しています。

・牛尾さん
はじめて牛尾さんのお話を伺いました。ワクワクする熱量ですね！
とーーっても楽しい時間でした！！

Serverless、分散処理、DDD、ヘキサゴナルアーキテクチャ、CI/CDの前提としてのUnitTest。どれもいつも関わっている内容なので「ですよね！」な共感がたくさんありました。

自動回復のために、リトライさせたい単位で関数を作る

ユーザーストーリーや、ユースケースを分解して、ドメインへ整理していく流れは意識していましたが、リトライさせたい単位での切り分けは、必要に応じて、程度でしか考えられていませんでした。自動回復を考えるなら、全てに適用ですね！
MdTranslatorのソースを参考にさせていただきますー

今回も、たくさん学びとワクワクをいただきました！
スピーカーの皆さん、運営の皆さん、ありがとうございました！

The Agile Guild(TAG) Advent Calendar 2018 9日目の記事として書いてみました。

> TAGに参加する
> TAGに相談する
どちらも、こちらのページから。