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に相談する
どちらも、こちらのページから。


この記事が気に入ったら、サポートをしてみませんか?気軽にクリエイターを支援できます。

note.user.nickname || note.user.urlname

いつも応援していただいている皆さん支えられています。

ありがとうございます!シェアしてもらえるとうれしいです!
2

諏訪真一

TAG DAYS

The Agile Guild メンバーのnoteをまとめています。
コメントを投稿するには、 ログイン または 会員登録 をする必要があります。