Toil撲滅活動に終わりは来ない / NoOps Meetup Online#0 LT

Transcript

1. 川崎 庸市 @yokawasa NoOps Japan Presentation slides for NoOps Meetup

   Online #0, Dec 16 2020 #NoOpsJP

2. http://noops.connpass.com/

3. Google SREのToilの定義 Toil is the kind of work tied to

   running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows. Toil 説明 Manual （手作業） 手動作業。手動でスクリプト起動することもToil Repetitive （繰り返し行うこと） 新しい解決策や発明がなく、繰り返される作業 Automatable（自動化できること） 自動化できない人の判断を要することはToilではない Tactical（割り込み、受け身の作業） Strategicでない、突発的に発生するアラート、オンコール対応 No enduring value（永続的価値がない） 次の改善や価値に繋げられない作業 O(n) with service growth（線形増加） サービス成長、ユーザ数など応じて線形増加する作業 Chapter 5 - Eliminating Toil in Google SRE Book

4. Toil削減活動 エンジニアリング力で継続的に”システム運用保守の嬉しくないこと”を削減するための活動 Manual Repetitive Automatable Tactical No enduring value O(n)

   with service growth 自動化 解決策の創造 自動化 戦略的対応 永続的改善・再発防止 スケールさせる VS

5. 技術的負債 Toil対応活動 vs. エンジニアリング活動（Toil削減活動含む） Toil対応活動 イノベーションとToil削減のための エンジニアリング活動 与えられた時間・リソース 50% •

   Toil削減に避ける時間が十分に取れず、技術的負債が増加していく • 新規開発やビジネスイノベーションに時間が避けなくなる

6. SRE活動内容例 信頼性・安全性の改善 SLI/SLOやエラーバジェットの設定 構成管理の自動化 Toilの削減 監視・観測・計測 ポストモーテム、再発防止活動 Infrastructure as Code

   (IaC)、CI/CD Blue/Gree、カナリアリリース テスト自動化 カオスエンジニアリング パイプライン化・マニュアル化
7. None

8. システムは生き物 生まれた瞬間に腐りはじめる 新技術の登場 ビジネス環境の変化 システム要件の変化 関わる人間の変化 https://unsplash.com/photos/rL7-pSUEj18

9. 経済産業省 DXレポート 〜ITシステム「2025年の崖」克服とDXの本格的な展開〜 （2018.9.7） 極端な例

10. 腐りすぎるとその 代償はあまりにも 大きい • 技術負債だらけ • 刷新できない • 捨てられない •

    新しい価値提供に集中で きない 経済産業省 DXレポート 〜ITシステム「2025年の崖」克服とDXの本格的な展開〜 （2018.9.7） 極端な例

11. 継続的にアップデートしながら進化できる状態 を目指したい • 安定的に生産、価値のデリバリ、改善のフィードバックループを回す • 空いた時間を新しい価値の創造や改善にまわす • トイルが最小化されている ⼈間 開発

    コード⽣産 履歴管理 パイプライン マーケット 監視観測・テスト （Observability） データ収集・解析（Data-driven） 価値のデリバリ ⽣産者 ⾃動化・⾃律化されたプロセス フィードバック

12. Application Platform / Backing Services Infrastructure ⼈間 • 開発者 •

    SRE コード管理 履歴管理 パイプライン CI/CD 監視観測・テスト データ収集・解析 feedback log, metrics, raw data delivery 構成⼒のあるアプリ・インフラ ライフサイクルが⾃動化されている Recovery process 回復性があるアプリ＋インフラ 回復性のあるアプリ • 必要な能⼒: self-healing, Auto Scaling, inflight renewal • 回復性に貢献するデザインパターン 回復性のあるインフラ • 可⽤性、弾⼒性がある設計 • Backing Servicesの活⽤ 可観測性のあるシステム • 状態・履歴を観測 • 観測された結果をフィードバック 復旧措置を持つシステム • 復旧措置（リカバリプロセス）+ SRE⼒ • ⾃動化、⾃律化できない、もしくは失敗したときの 復旧措置とそれを実⾏する運⽤⼒ • バックアップ・リストア、DRなども含む 継続的に運⽤サイクル を回していくための 組織・チーム編成 全ての経路・プロセスにお いて安全性(セキュリティ)が 担保されている feedback recovery NoOps的にはこんなイメージ

13. さいごに、今考えていることを強引まとめます 継続的なアップデートとは継続的トランスフォーメーションであり、言い方を変 えると不要なものを捨てて刷新すること だから規模は違えどその一部を捨てて刷新していくので、システムはいづれも捨 てやすい状態になっていることが理想なのでは？ また、現実的にこの活動を継続的に支えるためには エンジニアリングの観点だけ でなく、人・組織、経営者のマインドセット全てが整っている必要があるだろう NoOps Meetupでは今後こういったトピックの深堀り、チャレンジ、経験に

    ついても共有していければと考えています
14. None