🤖
自動化するときに暴走しないためのチェックリスト
本当に必要な自動化ですか?
自動化したい欲が暴走して、負債になってしまうことってたまにありますよね。
自動化に理解のあるチームであれば、自動化に対し好意的にとってくれるかもしれませんが、本当に有効なのか胸に手を当てて考える必要があります。
忘れないように自戒を込めてメモります。
自動化をする / しないは以下の基準で俯瞰した目線で判断されるべきだと思います。
自動化するにしても、負債にならないようなお作法は守られてますか?
自動化やるやら基準編
-
1週間のうちX時間はこのマニュアル作業に囚われている
デプロイ作業などは自動化すべきですし、年に数回しか発生しない作業であれば他にやるべきことがあるかもしれません -
この作業はシステムのアーキテクチャが大きく変更しない限りワークする
先週作った自動化が、最低でも半年後でも動いていることは想定しましょう。 -
自動化しない場合、深刻なオペレーションエラーが発生する可能性がある
頻繁に実施する必要のある作業ではないが、深刻なエラー(Sev1レベルの障害など)が発生するおそれがある場合は優先的に自動化しましょう
お作法編
-
冪等性はもっていますか?
多くの自動化において、想定外の失敗は発生しうるものだと想定してください。
そして、失敗したときに、後続の実行によって解決できるものであることを意識しましょう。
例えば、モニタリング基盤であるアラートは日中はOFF、普段はONといった運用をしており、ON/OFFがスケジュールされていることを想定します。なんらかの理由で失敗した際に、再実行で修復可能な仕組みであること(=冪等性)を担保していることは、もしものときに慌てないで済みます。 -
重大な影響を及ぼす自動化はフェイルセーフになっていますか?
例えば、何らかの理由でユーザを削除する機能があった場合、一人の意思決定や誤操作で実行できる仕組みになっていませんか? -
検証環境と本番環境を間違って実行してしまうような仕組みになっていませんか?
寝ぼけて、検証でのPush通知を本番で流して、Twitterに載らないように... -
自動化を構成しているコードやアセットはどこかで一元管理されてますか?
このソースコードが動いているっぽいけど、もっと古いバージョンかも、な状態を避けましょう -
クレデンシャルな情報は秘匿されてますか?
連携するサービスのアクセストークンはコードに埋め込まれていませんか?ログなどに誤って表示されるようになっていませんか?
GASなどは鍵情報をベタ書きするしかなく、そういった場合はそのファイルへのアクセス制御などにポリシーがありますか?
Discussion