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を作りたい