概要
現在SREとして働いているが、複数あるアプリケーションのリリース作業を依頼されることが多かった。
依頼者の職種はエンジニアやマネージャなど。
そのリリース依頼のほとんどを委譲したので、やったことを記録する。
課題
手作業
- 作業ミス
- 時間がかかる
- sshログインなどの権限管理
作業依頼
- コミュニケーションコストが増える
- デプロイしたものに問題があるかどうかわからない
- SREが休むととデプロイできない
- 作業依頼によるコンテキストスイッチ
- デプロイを忘れてしまう
- 誰に依頼するかわからない
- 作業状況がわからない
やったこと
なお過程も含むので現段階で使われてないものもある
自動化
- ローカルでおこなう手作業をCIで自動化
- オペレーションサーバに接続しておこなう手作業をバッチ化
- aws ecs run-taskとして実行
- Slackのワークフローによるテンプレ化
- 依頼のメンション先や作業順を固定化
- 作業状況をオープンに
- 通知
リリースを誰がいつやっているかわかるように
ドキュメンテーション
大体下記のようなことに気をつけて手順書を作成
いい手順書とは - tom-256.log
ほかにも下記のようなことを工夫した。
- 手順書を実際に使ってモブ作業する
- モブ作業の前に自分で手順書を使って動作確認する
説明するときに躓くと相手側が不安な気持ちになり、スムーズに委譲できないので作業時間を割いて実施 - 画像を用意して伝わりやすくする
- リリーステンプレを用意して、作業が終わったらチェックボックスを埋める
コミュニケーション
- モブ作業
- 移行期間を設ける
一度のモブ作業で終わるのではなく、複数回実施して段階的におこなう
- 移行期間を設ける
- ドキュメント
- 責任範囲の説明（定常作業担当と仕組みづくり・監視担当の棲み分け）
- 双方にとってメリットがあるという理由
- アフターフォロー
- 作業自体は委譲するが、改善案や相談があればすぐに伝えてもらう
- 問題があれば前のやり方に戻すことも可能であると伝える
ほかに気をつけること
- 自動化せずに委譲すると事故を引き起こす可能性が上がるので自動化してから委譲する
- 運用を見据えた設計をする
自動化可能か、仕組みとしてスケール可能か、チームとしてスケール可能か - 自動化のコストと実行頻度を考慮する
コスパの悪い自動化をしない
まとめ
やったことをまとめた。
一度委譲しようとして難色を示されたことがあったが、モブ作業などを整備して再びコミュニケーションをとったら委譲することができたので、 十分に準備をしてコミュニケーションする。
