こんにちは、KENTEMのまつです。
今年一年を振り返って、個人的に悔しかった出来事として、リリース手順の漏れによって時限式の障害を発生させたことがあります。
この記事では、何故障害が発生してしまったのか?と再発防止策について紹介しようと思います。
何故障害が発生してしまったのか?
ざっくり概要を図で表すと以下のようなイメージです。
注目して頂きたいのは、一度リリース手順の漏れに気付いている点です。
リリース手順書にコメントを残し、メンバーに共有を行ったにも関わらず、次のリリース準備ではその情報が失われてしまいました。
何故障害が発生してしまったのか?原因はリリース準備にありそうでした。
リリース準備における要因を洗い出してみると以下の問題を抱えていることがわかりました。
- リリース手順書の作成が属人化している
- リリース手順書のレビューが形骸化している
リリース手順書の作成が属人化している
リリース手順書の作成は完全に属人化しており、作成プロセスも作成者以外は把握していない状態でした。
作成プロセスをフローにしてみると以下のイメージでした。
赤く塗りつぶしてあるプロセスによって手順漏れの情報が失われてしまっていました。
手順漏れについては手順書作成者にも共有されていましたが、前回リリースから2か月の期間が空いたことで忘れ去られてしまっており、定型業務的に削除をしてしまっていました。
また、手順書確認者も同様に、2か月の期間によって忘れ去られており、レビュー時に気付くことができませんでした。
リリース手順書のレビューが形骸化している
リリース手順書のレビューは作成者が手順書を元に手順を説明し、確認者がそれに対して指摘を行うような流れになっていました。
本来全ての手順を1から確認していくべきなのですが、変更が無い部分がほとんどのため、前回と違う変更点のみのレビューになっていきました。
そして、前回と違う変更点は作成者から説明があるため、作成者が認識していない部分はレビューされなくなり、レビューが形骸化していたのです。
再発防止策の検討
これらの問題を解決させるために再発防止策として、以下の検討しました。
- 作成プロセスの明確化
- レビューが形骸化しない環境
作成プロセスの明確化
作成プロセスが明確になっていないがために属人化が起きてしまったと考えました。
そこで、リリース結果からのフィードバックを反映できるように、以下のようなサイクルを意識した作成プロセス作成することにしました。
レビューが形骸化しない環境
レビューが形骸化してしまった理由として、面倒くさいからだと考えました。
何故面倒くさいのか?
手順書はExcelで出来ており、前回と違う変更点がどこにあるのか、どういった変更をするのか、資料を作成するのは非常に労力がかかります。
レビューする人も同様に、その場でそれらすべてに目を通すことは非常に難しく、面倒でもあります。
そこで、定型化している作業はテンプレート化して、それ以外の作業は都度作成し、テンプレートとの差分を自動的に取得できるような環境を検討しました。
再発防止策について
検討の結果、さまざまな案が浮かんでは消えて、、としたのですが、今回は割愛して結果はExcel手順書からMarkdown+Git管理の手順書に変更することとしました。
Git管理
Git管理にリリース手順書のテンプレートを追加して、リポジトリの運用に組み込んだことで、リリース結果とフィードバックを受け取ることが出来るようにしました。 これにより、リリース手順書の作成プロセスを明確にすることが出来ました。
Markdownの手順書
Excel手順書をMarkdown手順書にしたことで差分の取得を容易にしました。
これにより、プルリクレビューが成立して通常のコードと同じようなレビュー環境にすることが出来ました。
ちなみに、Markdownの手順書は見にくいのでは?と当初考えていましたが、構成を工夫したり、VSCodeの拡張機能を利用することでExcel手順書と遜色無いレベルにすることが出来ました。 ※上図にはありませんが、画像を使った手順もあります。
以下VSCodeの拡張機能をインストールすることで入力の手間を軽くしています。
- Markdown All in One
- Markdown Preview Enhanced
特にMarkdown Preview Enhancedはマークダウンをプレビューしてくれる上に、チェックボックスをONにすると文書自体も変更してくれるので非常に助かっています。
Markdown手順書とGit管理が組み合わさることで…
ブランチイメージにあるプルリクレビューで色々な効果を得られました。
release/v00000_plan_draft ⇒ release/v00000_planのプルリク
テンプレートとリリース手順書の比較をすることでどのような定型作業があり、定型外の作業はどれだけあるのか把握しやすくなりました。
release/v00000_plan ⇒ release/v00000のプルリク
リリース結果とテンプレートに追加で必要になった手順(つまり定型になる作業)が把握しやすくなりました。
おわりに
今回、Excel手順書を脱却してMarkdown+Git管理の手順書に変更しましたが、Git上でExcelの変更差分を出すプラグインもあるようです。
他にもGitに限らず様々な方法があると思いますので、あくまで一つの例として捉えていただいて、皆さまのデベロッパーライフに少しでもお役立て出来ればと思います。
KENTEMでは、様々な拠点でエンジニアを大募集しています! 建設×ITにご興味頂いた方は、是非下記のリンクからご応募ください。 recruit.kentem.jp career.kentem.jp