2018-12-07 NoOps Meetup Tokyo #3
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に相談する
どちらも、こちらのページから。
この記事が参加している募集
いつも応援していただいている皆さん支えられています。