この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
先月（3月）の 6日に、「ヤマサキ春のサメまつり」と題して開催された #ssmjp 2019/03 。その名の通り JAWS DAYS 2019 の裏話からチョウザメまで様々な「サメ」にまつわるプレゼンテーションが行われたのですが、その中でいちばんアウェイ感の高かった（主観）「運用自動化」の話が個人的に非常に興味深かったので、個人的に重要と思ったところを中心にご紹介します（一ヶ月近く時間が空いてしまいましたがご容赦下さい…）。
話者は、 2017 年に有名な 運用自動化、不都合な真実 のプレゼンを行って以来 「不都合」のハタノさん と呼ばれ、今年（2019年）は 正しい「運用自動化」の考え方を広める人（に私はなりたい） と公言されている @tcsh （波田野）さんです。
（画像は JAWS DAYS 2019 「AWS CLIではじめるコマンドラインライフ 〜 正しい「運用自動化」への第一歩」より）
なお、発表時点よりスライドが追加されているとのことです。
昨日の質疑応答で、「運用自動化3つの視点」の適用についてご質問いただいたので、スライドを追加しました。このスライド追加でより整理しやすくなったと感じています。ありがとうございました! #ssmjp pic.twitter.com/4B2o3HlT3e
— HATANO Hirokazu (@tcsh) 2019年3月7日
該当箇所の質問は私がさせて頂いたのですが、明快に回答頂いただけでなく図示までして頂けたため、とてもクリアに理解することができました。本当にありがとうございました！
「運用自動化」とは
2019-03-06 「運用自動化」とは /20190306-operation-what-automation - Speaker Deck
「運用」とは
- その他扱いになることが多い
- （字義より）「何かを活用」しない活動は「運用」とは言えない
- 運用を「サービスデリバリ」ととらえる
- 運用は「リクエスト(要求)」に対する「デリバリ(提供)」の繰り返し
- そのメリット
- 専門性が明確になる
- （監視システムからの）アラート対応 = 復旧リクエストに対するサービスのデリバリ
- サービス(目的) = ユーザの「課題」を解決すること
- デリバリ(手段) = サービスを安定的合理的に提供すること
- 本質は「事業継続性」の実現
- 運用における 2つの価値と事業継続性
- サービス価値（ビジネス）とデリバリ価値（エンジニアリング）
- ビジネスの全体最適化
- 現場という部分最適化
- 両方の継続がそろわないと「事業の継続」が可能にならない
- 「運用」と「operation」はイコールじゃないかもしれない
- 字義より
- [医療] 身体を治すこと、不具合を取り除くこと
- なされた作業(work)・行動(activity)、あるいはその過程(process)
- 翻訳本を読み進める上で常に頭に置くべきポイント
- 字義より
「運用自動化」とは
運用自動化 = サービスデリバリを自動化すること
- 本質は 「事業継続性の向上」
- サービス視点で設計・実装
- デリバリ視点で定量評価
運用自動化 = 運用標準化の一つ
- 運用業務をコードレベルまで定形化し、実装まで行うこと
- 社内製手運用 -> 運用定形化(手順書) -> 運用自動化(コード)
- コード化の前に手順書化する
- 「自動化すれば定形化される」わけではない
- 定形化しない自動化は一番やっちゃダメ
- 設計なき実装に陥る
- 仕様バグを生みやすい
「運用自動化」3 つの視点
- 視点 1 : 企業の事業継続性向上に貢献するか？
- 事業継続性が向上しない自動化は運用自動化ではない
- 変化に追随できない自動化はだめ
- 自動化は業務硬直化させる
- 視点 2 : 運用現場のサービス価値向上に貢献するか？
- 運用自動化はユーザには関係ない
- 「手動か自動か」より「品質や納期」
- 自分たちの雑用を解決するだけの自動化は運用自動化ではない
- 視点 3 : 運用現場のデリバリ価値向上に貢献するか？
- デリバリ視点で定量評価する必要がある
- 運用自動化は「目的」になりやすい
- 導入自体が成果になりがち
- 成果目的の自動化 = 焼き畑農業的な運用自動化
- 3つの視点をはずさないようにしないとならない
ダメな「運用自動化」の3類型
2019-03-06 ダメな「運用自動化」の3類型 + α /operation-automation-3-bad-model - Speaker Deck
類型 1
- 事業継続性が向上しない「運用自動化」
- 変化に柔軟に対応できない
- 人の異動に確実に対応できない
- ＝ 自縛自動化
- 業務を硬直化させる
- 進化すると自爆自動化
- 自動化のメリットを上回る致命傷
- ただし
- 趣味でやるのは問題なし（やらかす前提）
- 業務でやるのはダメ、絶対
類型 2
- サービス価値が向上しない自動化
- ユーザの課題解決に貢献しない
- 自分たちの雑用を解決するだけ
- ＝ 雑務自動化
- トイルの撤去
- サービス価値には関係ない
類型 3
- デリバリ価値が向上しない自動化
- 反復性・再現性・安定性・合理性のない自動化
- 定量評価による検証をしない
- ＝ 趣味自動化
- 自動化そのものが目的になっている
- プライベートでやる分には問題ない（むしろ経験値up）
類型 番外
- 動かない「自動化」
- 「運用自動化」に不可欠な3つの視点の外側の人
- 成果目当て（運用自動化が目的）-> 趣味自動化
- 自動化によって全てが解決すると考える人
- 多機能・完全自動化を夢見る人
- ＝ 夢想自動化
- 壮大すぎて実装しない・できない
- 進化すると無双自動化
まとめ
- 以下は「運用自動化」ではない
- 自縛(自爆)自動化 - 業務を硬直化・破綻させる
- 雑務自動化 - ユーザの課題を解決しない
- 趣味自動化 - データによる効果測定をしない
- 以下は「自動化」ですらない
- 夢想(無双)自動化
所感
「運用と operation はイコールじゃない」というところから始まり、全てが普段もやもやしていたところを明快にしていただけたセッションだったと感じました。
「運用自動化」というと「何でも自動化で ok 」となったり、逆に「信用ならないから使うな」となったりと、両極端に陥りがちな印象がありますが、その根底には「『運用』という言葉が指し示す範囲が広すぎる・曖昧で人によって定義が異なりすぎる」という面があると考えていました。このセッションで示された「運用自動化の定義・視点」を念頭に、その使いどころを見極めていきたいと思いました。
ちなみに弊社の場合、全体的に「やってみて失敗して経験値を積むことが業務活動」という趣(おもむき)があって、それと「運用」の線引きが難しく悩ましいところです...ｗ 氏の「運用自動化の基本原則」シリーズはこれからも続いていくとのことなので、ここから得られた知識をベースとして日々の業務に生かすべく、楽しみにフォローしていきたいと思います。
余録
この記事を書くためにいろいろ見ていたら、下の URL を拾ったので貼っておきます。
7
