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