Navigation Menu

Skip to content

Instantly share code, notes, and snippets.

@sunaot
Last active March 8, 2018 14:36
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save sunaot/3323744f68ea5e35895871637e72c8fd to your computer and use it in GitHub Desktop.
Save sunaot/3323744f68ea5e35895871637e72c8fd to your computer and use it in GitHub Desktop.
リハーサルというものはだなの文章

リハーサルはなぜ重要か

(実施告知の文章から抜粋)

ええと、みなさんAWS移行の準備も大詰めでリハですね。リハーサルってなぜやるかわかってる人もわかっていない人もいると思うので書いておきます。結論を先に書くと、本番当日もそのまま手順を踏襲するとそれで移行が終わる詳細な手順が書かれた移行手順書を書いてリハをしてください。リハの中で手順どおりには行かなかったところはその時にすべて手順書に反映して、本番のときは手順どおりでやれるようにしてください。

本番一発勝負というのは難しいもので、人間どんなに考えていても失敗します。でも失敗を糧に二度目をすると一度目にやった失敗は回避できます (できるようにします)。システム開発というのは一般的に大体予測不能なところで失敗するものなので、一度本番同様に動かしてみるというのが非常に重要になってます (アジャイルが繰り返し開発するのも動くソフトウェアを信じるからですね)。

性質として事実上そういうものなのですが、私達の気持ちとしては当然失敗はしたくありません。そこで、失敗をするはずの一度目としてリハーサルという疑似本番をやるわけです。そうすることで、失敗の予行演習ができます。本番に向けて失敗の予防ができます。ここを人手でやると再現性が落ちるのでベストは自動化され、何度やっても繰り返し同じことが実現できる状態です。でも、それはしやすいものとむずかしいものもあるので人間がそのとおりに実行をしたら同じ結果になるという手順書というのが大事になってきます。

今回のリハーサルでは、「本番ではその手順以外にはなにもしないでもAWS移行ができる」という手順書をつくることを目的にしてください。手順に書くか書かないか、どこまで書くのかといったことはすべてここを起点に判断してください。

そこまでやっても、きっと本番では想定外のことがあります。そこへ対応できる当日の余裕があるかどうかというのは事前の準備しだいになってきます。

(がんばりましょう的なことを書いて〆)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment