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