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 Meetup Tokyo #1 Opening
• NoOps?よろしいならば戦争だ
• NoOps at Yahoo! JAPAN #NoOpsJP
• 15分で分かる NoOps
• とぅぎゃり：NoOps Meetup Tokyo #1 recovery( #NoOpsJP ) - Togetter

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.機能追加で手動運用が増えても、２で自動化
  • システム規格時点で、非機能要求のハードルを思い切り上げる（頭をつかう）
• 付録：CnCF Landscape みたいな NoOps Landscapeを作りたい