Edited at

NoOps Meetup Tokyo #1 カンファレンスノート

2018/9/12 NoOps Meetup Tokyo #1 に参加してきましたので、いまさらですがノートを残します。


イベント情報

NoOps Meetup Tokyo #1 recovery - connpass

資料もこちらにいくつか上がっています。


NoOps = No "Uncomfortable" Ops

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

NoOps meetup Tokyo #1では、Architecture、Technology、SRE のそれぞれの分野で活動されている第一人者の方より、NoOpsへの取り組みやスタンスについてお話しいただきます。



資料リンク集


NoOps?よろしいならば戦争だ / 真壁 徹 @tmak_tw 日本マイクロソフト


  • 誰もがOpsを抱えている、Dev-Opsは単純化しすぎ

  • 現状認識


    • 新しく作るシステムはNoOpsしやすい(GreenFiled)

    • SRE組織化するが、従来型の運用も残る

    • 自動化、無人化の裏で人間が関わっており、自動化が壊れたときは人間が運用する



  • GreenFieldパターン


    • 新しく作るシステムはNoOpsしやすい、アプリ実装者がNoOpsを考えた設計をする



  • 運用者の自発的進化(リアクティブ)


    • 日々やっているプロセスや作業を進化させ、トイルをなくすパターン、アプリの作りまで踏み込まないことが多い



  • SRE組織化パターン(プロアクティブ)


    • より能動的に可用性を高め、アプリの作りまで踏み込むアドバイザーとなる



  • NoOps Japan Community への提案


    • Disらずに改善しよう

    • べき論はいらない(ハードル上げすぎない)

    • やめるファースト



  • NoOpsな技術とストーリーを共有し、コミュニティと「決定者」へコミットしよう


コンテナにおけるNoOpsオートメーション / Ian Lewis @IanMLewis Google


  • NoOpsはOpゼロではなく、Automationを増やすことによりOpを減らす事が目的


    • NoOpsというかLess Ops



  • LinuxカーネルとApplicationはAPIでやりとりしているので、ContainerはLinuxカーネルとApplicationのAPIと考えることができる

  • ApplicationはServerless APIのレイヤを挟むとよりロギング、モニタリング、Scaling等のレイヤも疎結合にできるのでAutomationに役立つ


わが家のNoOps / 塚 譲 Yahoo! JAPAN



  • @ITの記事読んで

  • SRE的価値観;Toilを無くそう


    • リアクティブで対症療法をやっていくのではなく、プロアクティブな改善していくほうが楽しい

    • 真面目にSREをやるとNoOpsの価値観に行き着く、効率良く働くことが大事



  • 1.可観測性(Observability)を向上させる


    • 向上→監視、計測、分析、追跡...

    • やらないことを決める、経過観察や評価手法を計測



  • 2.チームができることを増やす


    • モダンな働き方へ;自働化、ペアプロ、モブプロ、開発基盤の提供

    • 自分たちがいいチームになる


      • 誰かのために働く;僕は部員のために、チームは社内クリエイターのため、社内クリエイターはエンドユーザのために

      • チームのToilをなくす、社内クリエイターのToilをなくす、ユーザのToilをなくす

      • リードタイムを短くする;イテレーションのゴールに注力、定期に安定した機能を提供し続ける






NoOpsの目指す世界 / 岡 大勝 @okahiromasa NoOps Japan 発起人


  • NoOps = No Uncomfortable Ops(嬉しくないOps)


    • ユーザの体験を妨げないシステム運用保守の実現

    • 運用保守の現場で発生するトイルの最小化

    • システム運用保守のリリーススとコストの最適化

    • 利用者の利益とOpsの負荷は比例する



  • 価値観の転換


    • 10年末前:「壊れないシステム」「MTBF至上主義」

    • いま:高価な専用機器を大切に使う -> 安価な汎用機器を入れ替えながら使う



  • 回復性 が重要に


    • Design for Robustness(堅牢性) -> Design for Failure(対故障) -> Design for Resiliencty(回復性)

    • 物理クラスタ -> 仮想マシン・VM -> サーバレス・コンテナ

    • 壊れない -> いつでも回復できる へ

    • 高い復元力があれば:障害発生時の自己回復、オンザフライでのインスタンス変更、秒単位のスケールアウト/イン(コスト最適)

    • 必要な能力:Observablility(観察力)、Configurability(構成力)、Resiliencability(復元力)



  • レイヤ


    • ミドルウェアだけでは不十分、アプリケーションにも回復力を持足せる必要がある

    • 処理単位を小さく、ステートレス、非同期、冪等性、処理結果を記録、

    • いつ落ちても、どこで落ちても



  • NoOpsを実現するチーム(サイクル)


    • 1.回復性設計を最初に行う

    • 2.運用保守エンジニアリングで手動運用を自立化

    • 3.機能追加で手動運用が増えても、2で自動化

    • システム規格時点で、非機能要求のハードルを思い切り上げる(頭をつかう)



  • 付録:CnCF Landscape みたいな NoOps Landscapeを作りたい