運用にも運用自動化にも「銀の弾丸などない」

初ssmjpでブログ枠で参加しましたが、スライドのペースが速く、そこをまとめても、粗悪なスライドのコピーにしかならないので、発表者にて公開されているスライドを見ていただくのが一番のように思いましたので、その部分はあとのメモとして簡単にまとめる程度にとどめています。

どんなに傷ついても人は生活をしていかなくちゃいけない。だから傷にかさぶたを作る。そうすると痛むことはなくなるけど癒えることもなくて、残ったままそこにある。

村山由佳 「天使の柩」電子書籍版 特別収録のインタビューより

自動化に夢を求めて痛手を負いかさぶたを作る、そこにかさぶたに触れて、思い出す痛み、語られる「運用自動化の不都合な真実」。出席者の多くの方が、発表内容にうなずいておられたようです。それだけ自動化で傷を負った人が多いということでしょうか。

セッション中感じたことは、このひとことに尽きます。

運用にも運用自動化にも「銀の弾丸などない」

自動化が目的にはなり得ないこと、効率化=「重要な時間やお金を効率的につかえるようにする」ための手段であるということに同意します。自動化を目的にすることは「手段のためには目的を選ばず」ということになってしまいます。

筆者は、主に運用ツールを作成し保守する側で、作成したツールも運用過程で修正が入ったりしましたが、多くはシステムのライフタイムの方が先に来て、ツールの利用も終了するケースがほとんどでした。ただし、中にはメンバーが作成したプログラムが、運用で使うようになって数年後、作成者がいなくなってから、バグが発覚して炸裂というケースはありました。また運用過程で状況の変化などでパッチワークのような修正を行うこともありました。

過去の経験からも、手順をコードに落とし込むには、業務の定義を論理的に文書化するステップが必須です。コード化、自動化した部分の寿命は対象システムのライフタイムを超えることはできません。このため汎用性は不要です。むしろ、環境や状況の変化により、手順の修正が出てきたときに、外部インタフェースは変わらないようにするために、アドホックな対応で手順やコード部分を修正することになってしまいがちです。さらに、運用チームの中で誰かが修正するとなると、プログラミングにはあまり慣れていない人が担当することになるため、根本的な修正は困難です。したがって、実装は対象依存の使い捨てと考えるべきといういうのも頷けます。

自動化、ツール化は、平準化の側面が強いように思っています。この点についても考えが一致するところです。

発表資料で、「運用自動化」は「運用標準化」のひとつとありましたが、ここでの「標準」という言葉は、対象システムについての rule や referrence など、規準となるものを意味して用いられています。「標準」と書くと複数システムを跨いだ common standard のようなものを夢見てしまいがちなので、使いかたが難しい言葉であります。

SRE本のなかで、筆者が気に入っているこのような一文があります。

15.1 Google’s Postmortem Philosophy

You can’t “fix” people, but you can fix systems and processes to better support people making the right choices when designing and maintaining complex systems.

15.1 Google におけるポストモーテムの哲学

人を「修正」することはできませんが、システムやプロセスを修正して、複雑なシステムの設計やメンテナンスを行う際に、人々が正しい選択をすることをうまく支援するようにはできます。

「自動化」は運用において起こりうる誤りを減らすこと、運用において正しい選択ができるように支援するための「手段」だと思っています。自動化による工数削減は、トイル(toil)に割かれる工数を、エンジニアリングに向けるための「手段」であり「活動」です。そして、自動化によってコスト削減が図られたのであれば、その浮いたコストを業務改善や品質の向上、そして教育に向けることが必要だと思っています。

「もしハタ」について、『「運用改善」を考える 〜「自動化」を考える前に』を読んで、運用改善を実践できるには、それなりの運用についての痛みがわかっている必要があるというだけでなく、@Typhon666_deathさんだからできる行動力が光っているセッションでした。

「手順書の話」については、人を動かして処理するプログラムのようなものと捉えるのは、ここしばらく手順書の書き方について指導してきた身としては概ね同意です。結局のところ、手順書を、過不足なく、制約と実行内容とを「これだけ・このように」書くには、日本語文章力そのものに、プログラミング能力とおなじような論理的・数学的な思考力を必要とするのですが、そこを身につけてもらうにはどんなトレーニングが必要なんだろうかと感じています。

初ssmjpでしたが、時間の制約上、ssmjpの中でディスカッションすることは難しいので、同意するけれど、物足りなさを感じました。別の機会にでもかまわないけれど、ディスカッションする場がほしいなと思いました。

以下、当日のメモ

2017/12/12 ssmjp

スケジュール

19:20-19:30 ssmjp運営陣+ヒカラボ様 前説と会場について

19:30-19:50 @tcshさん 運用現場におけるSRE本の「正しい」読み方

19:50-20:10 @Typhon666_deathさん もしそこらへんの運用担当者が波田野 裕一の『「運用改善」を考える 〜「自動化」を考える前に』を読んだら(もしハタ)

20:10-20:20 休憩

20:20-20:40 @togakushiさん 「手順書の話」

20:40-21:00 @tcshさん 運用自動化、不都合な真実

21:00-21:30 懇親会(運営陣による2017年の振り返り)

運用現場におけるSRE本の「正しい」読み方

自動化された業務の保守が属人化

仕様が不明なため変更ができない

自動化ツールに完全に依存しているため、トラブルが起きてもツールが修正されないとリカバリできない

SRE

「ソフトウェアと自動化」役割を定式化

発展途上の未確定概念

• 本書から得られる真の財産は本書を読んで生じる様々な疑問
• 読み手によって実践のブレ幅が出る
• 魔法的な技術の話は出てこない
• 組織論がメイン

google → できないことを精神論で片付けない

google だからできること

• ソフトウェア工学、情報学、数学 などの研究 知見を反映
• ビジネスを根幹から見なおす風土がある
• 意図的に稼働率を100％未満に固定できる組織
• コードや実装よりも理論やドキュメンテーションが重視されている

「できないことを精神論で片付ける」チーム

• 人材 たたき上げが多い、
• 組織 手の届く範囲での解決
• 理論やドキュメントが苦手

SREで最初に重視すべき精神(私的視点)

• ビジネスのスケーリング
• 単純性という品質
• ドキュメント駆動運用

SREとは距離があるところ

• 最高の人材： Ph.D or 相当 の人材を増やす
• 根本から変えられる組織
• ドキュメント駆動運用

運用は 「operation」か? おそらく not equal

トイル vs 手作業の価値

コストの合理性: → もし手作業のぬくもりに3倍の価値を払ってくれるお客さんがいるなら、手作業の価値を認めてもよい
  

SRE本の歩き方

まず「UNIXという考え方」、その後すぐ後SRE本

3部 実践 あとでもよい

序文 超重要

2部 重要

まず全体を読む

もしそこらへんの運用担当者が波田野 裕一の『「運用改善」を考える 〜「自動化」を考える前に』を読んだら(もしハタ)

夏 インターン生：テーマ 運用改善に、製品検証

運用設計委には痛みの経験が必要 → 教材： 波多野さんのスライド、ラックの武田さんの連載

異動 2016/05

• これがない
• これしてない
• これができない
• 引き継ぎされない

運用でカバー ではなく → 残業でカバー

• 問題と思ったこと多数
• 対策方針 意味不明
• 障害報告を減らそう
• アウトソース 手順がないからできない

自動化が目的ではない

現状把握

See 現状把握

Plan 計画 ← ここで運用設計を想定 文書に書き起こす

Do 実行

アイデア ←反復→プロトタイピング  を 繰り返し

他部署と共有

インターン生が考えたプラン：

インプット スライド アウトプット good だった

「とにもかくにも 波多野さんのスライドを読め」

「手順書の話」

オンプレ、Excel方眼紙、ピンキリの人材

手順書に求められること

• 誰のために
• 責任者に承認してもらう
• ゴール

仕事の捉え方 スライド参照

INPUT PROCESS OUTPUT

手順書も分解

• 目的、結果、手順

これの積み重ね

手順書はプロセスを並べたもの

プログラムに似ている

人を処理する

例外は停止でよい

依存関係

• 事前、排他、事後
• 5W1H

チェック項目 ← ここに制約がある

すべて明確か?

• 確認
• 手順の正しさ
• テストが書ける?

読み替え、順序の入れかえを行う必要があるのは悪い手順書

準備不足

例: カップラーメンを作る工数

• 手配、お湯、開封

作業時間見積もり

• 準備の時間を含める
• 足りないより余る方がまし

手順書の最適化

• 時間に余裕があるなら、わかりやすさ、間違えにくさを優先すべき

• レビューでグダグダになることも
• 回数を重ねてブラッシュアップ
• 最後は権力発動

運用自動化、不都合な真実

運用自動化でひどい目にあったことはありませんか

実装： つくるとたのしい 褒められる

管理職： 工数削減

メンバ： 実現できればうれしい

それぞれに夢をもつ。さらに「褒められるとうれしい」

導入後：メンバーは、ミスマッチを“隠れ「運用でカバー」”する。

破綻潜伏期：推進した人や実装した人がいなくなるなると“隠れ「運用でカバー」”が永続化

破綻顕在期：OS、ミドルウェアのEOL、仕様変更、バグの顕在化 

環境変化、仕様のバグ、やっつけ修正綻びが出てくる→積み重なりさらに綻びが大きくなる

破綻炸裂期：業務遅延 手動迂回、信頼性 低下 手動確認、最悪 業務停止

忘却期：システムのライフサイクル的に周期のこのあたりで更改が入り、新規システムにリプレイスされ不都合が忘れられる？

「運用自動化」とは何か

• 運用業務のコード化
• 定型化 標準化

すべてをコード化する必要はない： 工数、スキル次第

自動化は定型化でない

• 汎化できない
• 目的になりやすい

自動化は効率化の手段

• 目的にはなり得ない

「運用自動化」3つの不都合な真実

1. 自動化は業務を硬直化させる

• 柔軟性が減る

2. 「やれるところから自動化」はキメラ化しやすい

• 連携がとれない
• 手作業による、ツールのつなぎ

3. 自動化の寿命は短い

• 技術の変化、バージョン、EOL
• 業務フローの変化についていけない→頑張っても、あっという間に負債化、無価値化

どうするか

• 使い捨てのつもり 陳腐化したら作り直す
• 汎用性は不要
• 夢のツールは無理

外側(インタフェース)から自動化(正規化)

疎結合、分散型の小さなツールを組み合わせる

ツールが止まっても運用が止まらない→人手にフォールバックできること

Whyを残す

ドキュメントは資産、ツールは揮発物

工程の意識

作業の場所が変わるなら分割

作業手順の主目的で分類: 作成、確認、削除、更新

適切はドキュメントの存在が自動化を支える

成功パタン

• 明確な目的からトップダウン
• 効果の before / after が明確
• メンテナンス性 疎結合な
• 手順書に沿って作成したもの 手順書（プロセス定義がまずあることが前提）

失敗パタン

• ボトムアップ式
• 「自動化」を目的
• 「夢のツール」を目指す

外部からみたとき、高品質、適正コストであればよい

自動化の有無は不問

適度に適材を適所に

手作業に高価値を見いだしてくれるなら手作業

工数削減を目的にしない

工数が少し増えても提供価値が増えればよい

工数あたりのアウトプットを増やす

自動化だけに依存しない、手動対応で動けるのがプロの自動化

重要: 運用自動化をしっかり実現するには

 使う人が自分で作るしかない、という結論