SRE Advent Calendar 2019 14日目の記事です。
皆さんこんにちは。都内某社でSREっぽいことをしているものです。SREを名乗り始めてから早2年も経過してしまいました。
本記事では日々のモチベーションを削ぐToilの削減についてこの2年間一体何が出来たかを振り返ってみたいと思います。
Toilの定義
まずはおさらいとしてToilの定義を復習しようと思います。
英単語的な意味は「骨折る、骨折って働く、骨折って進む、難渋しながら歩く」ですが、GoogleのSRE本 では下記のような作業と定義しています。
- 手作業（Manual）
- スクリプトの手動実行も含む
- 繰り返し作業（Repetitive）
- 自動化可能（Automatable）
- 戦術的（Tactical）
- 割り込みで作業が発生する
- On-call対応とかも
- 永続的な価値なし（No enduring value）
- サービスの成長に比例して増加する （O(n) with service growth）
雑に言うと何度も発生するしんどい手作業という感じですね。
GoogleのSREでは「エンジニアリングプロジェクトに工数を割くために、Toilを全体の稼働時間の50%未満に抑える」というのを目標として掲げています。
Toilは機械的に作業するだけなので少量であれば手軽に達成感を味わえるタスクになりえるが、大量に存在すると害になるとも書かれています。記載内容については共感しかないですね。（ぜひご一読を）
Toilの認識
まずToilを認識できていないことには話は始まらないと思うので、普段やっている業務の何がToilに該当するかを把握するのがまず最初のステップな気がします。
私個人がまずやったこととしては、手作業が発生したタイミングでそれをスプレッドシートに列挙していきました。（当時、一覧的なものはなかったので）
項目としては下記を記載していきました。
- 作業分類
- 作業を大まかにカテゴライズしたもの
- 作業名
- 所要時間
- 最初はTogglで計測したりもしましたが、けっこう適当
- 作業手順のURL
- 既にあるものはURLを記載（各所に散らばっていたりする）
- 無いものについては作成して記載
- 自動化手段
- なにか手段がありそうならそれを書く、基本的に妄想
これにより、作業が決まり決まった手作業で、なおかつ自動化手段がありそうなものがToilなのかなと、ざっくり判定することが出来るようになりました。
...Toil定義のManualとAutomatableしか確認出来てないやんけ！という指摘があるかと思いますが全くもってそのとおりです。Toilの定義をちゃんと詰める前に一覧化し始めてしまったのでこんなことになってしまいました。
ちゃんとした整理方法はBizReachさんの素晴らしい資料（Make it Visible - BizReach HRMOS SRE Team's Observability Strategy）があるのでp25あたりを見てもらえれば良いと思います。こっちのほうが絶対いいと思います。
Toilの計測
そもそもToilを削減すると言っても、削減できているかを認識できる必要がありますよね。ただ、依頼手段が複数あると件数を正確に把握することは難しいと思います。
- Slackでフランクにされる依頼
- メール依頼
- 口頭依頼 等
依頼メールの件数の確認やSlackの依頼数から件数を確認するのは意外と大変かと思います。フリーフォーマットだと依頼かどうかの判断も難しいですし、ちゃんと返信などを除外してカウントしないといけなかったりもします。
最初の状態
依頼がどのくらいあるのか正確に把握できていない状態です。
改善後
そこでJIRAに確実にチケットが作成されるようにしました。
仕組みはこんな感じで、フォームから専用のアドレスにメールを送信して、JIRAのメールを受けたら起票出来る機能を使ってチケット化しています。
Slackでのやり取りも気軽に行われますが、本当に軽微なもの以外はフォームからも申請してもらうようにしました。
※ この辺の仕組みについてはつい最近更なる改良が施されました。そちらについての詳細はこちらの弊社ブログに書かれています。
※ JIRA Service Deskは2018年3月頃にちょろっと試してみたりはしましたが、別に創意工夫でなんとかなる範囲だったのでケチりました。
※ Toil担当を週替りで1人が担当するルールにしました。これにより担当外の人は自分のプロジェクトに集中することが出来ます。（が、流石に件数が多い場合は普通にヘルプを頼みます）
これにより依頼件数（≠Toilの数ではありますが）が計測できるようになりました。
自動化したりツールを導入して依頼者側で対応可能にしたりした後で、この件数が減少していけば効果があったということになります。
可視化
一応こっそり可視化もしてます。
着手から完了までのDurationも取ってはいますが、承認待ちが発生する作業については実際に要した時間よりかなり大きい値になるのであまり参考にならないです。
フォームで選択できる依頼種別ごとのカウントなんかもあったり。
これで優先的に潰すべき件数が多くてなおかつ時間がかかっているやつがなんとなくはわかります。
Toilの削減
Toilが大体わかったところでそれをどうやって削減していくかという話になっていきます。
権限見直し＆付与
真っ先に出来ることではありますが、権限を見直しそもそも権限をつけていい人には権限を付与する、というのがかなり効果的な気がします。もちろんセキュリティ面が疎かになってはいけないので渡せない権限はまだまだありますが。
自動化
- マージ契機で実施するような作業はGitLab-CIを利用
- 権限を単一ディレクトリサービスに集約して都度設定不要にしたり
とか？まだそんなには出来ていない気がします。やっていき。
半自動化
このあたりが今の所一番多い解決策な気がします。
-
Jenkinsおじさんによるジョブ化
- 作業をスクリプト化して、パラメータ付きビルドで必要事項を埋めてもらって実施してもらうパターン。
- ジョブの実行結果だけがSlackに通知されるようにしています。
- 自由度高し。
-
Ansible AWXによるジョブ化
- ご存じの方も多いとは思いますが、WebUIやREST API経由でAnsibleのPlaybookを実行できるツール。
- サーバのroot権限は渡せないけど、ある程度自由にroot権限が必要な構成変更を適用してもらいたいときに役に立ちます。
- SURVEY機能を使うことでJenkinsのパラメータ付きビルド的なこともさせられます
- Netboxというインフラ管理ツールとのDynamic Inventoryによる組み合わせに可能性を感じてはいるが、そもそもNetboxの管理がめんどくさい問題
やっていった結果発表（暫定）
Toilは果たして減らせたのか？という結果についてですが、結果としては...数値上はまだそんなに減って無い気がします！
理由はいくつか考えられますが、まあどれもしょうがないかなと。
- 組織拡大に伴って対応すべきプロダクトの数が増えている
- 組織拡大で人の出入りも増え、それに伴う雑務が増える（完全には自動化出来ていない）
- そもそも過去のフォーム利用率が低くて、フォーム利用率が上がる（喜ばしいこと）だけで数値が増えてしまう
なので、増加が抑えられていれば我々の勝利なのでは？という気もしますね。まだ負けてない。減らせればもっといいけれど。
おわりに
Toilから開放された生活はまだまだ先になりそうではありますが、よりエンジニアリングに時間を使えるように推進していきたいなーと思いました。ただ、気をつけなくてはいけないのは、単純にToilを他者にオフロードするだけだと全体的なToilは減らないということです。その辺にも気を使いつつ進めていかないとなと思う次第であります。