XML
Webアプリケーションのリリース時は大変緊張するもので、それはWeb(インターネット)に公開することイコール、世界中の誰にでもアクセスが可能になるためである。といってもWeb以外でもお客さんに納品するタイミングというのは平常時の精神状態ではないため、普段ならおきないミスも発生してしまうリスクがある。リリースするまでのテスト手法などは記述するとキリがないため省いて主に、私の経験上いかにリリース時にトラブルなく、リリースできるかリリース前日、当日、後日の心構え的なことが中心にまとめてみた
3日前迄にやること
リリース手順書の作成
リリース時にやるべきこと(作業内容)を、記述したドキュメントを作成するのとしないのでは、雲泥の結果を生み出す。何回もいうようにリリース時にはどんなに肝っ玉が据わった人でも平常時以上の判断・能力を発揮することはできないので、頭をつかわずとも、リリース作業ができるように前もって手順をまとめておくためである。誰(Who)が何(What)を何時(When)にどう(How)すべきなのかを明確化することが大切である。後は、開発環境では問題なく動作しているプログラムも、本番環境だと動作しない(※ミドルウェアのバージョンや、サーバの設定が異なっている事により発生しやすい)ケースがある。
ケースによっては巻き戻しフローも明記しておくこともある。すでにサービスを開始しており、リニューアルや、機能追加の場合では、サービスを継続すること(※サービスを止めない)が第1だと思う、前のバージョンに巻き戻す事を巻き戻し作業と呼びます。作業内容が決まれば、作業完了時間が決まる。その時間完了時間から1時間以上オーバした場合、リリース作業を急遽取りやめ、巻き戻し作業に入るわけである
(参考例)
[12/01 11:00～12:00]
AさんがプログラムをサーバにUPする
UPするソース(○○.php、□□.php、△△.php)
[12/01 12:00～13:00]
BさんがApacheの設定を変更する
変更するファイル(httpd.confのline:412)
○注意箇所
httpd.confのバックアップ(httpd.conf_bak)を必ずとっておく
変更後、apacheの再起動を行う
[12/01 13:00～13:10]
BさんがIP制限を一部許可する
変更するファイル(httpd.confのline:102)
○注意箇所
念のため非許可IPの箇所よりアクセスし、制限が
かかっているか確認を行う
変更後、apacheの再起動を行う
[12/01 13:10～14:00]
プロジェクト関係者全員で確認を行う
○主に確認する箇所
Aさん(入会登録)
Bさん(購入、決済)
Cさん(商品の表示)
[12/01 14:00～]
リリース無事完了
[12/01 15:00を超えた場合]
●巻き戻しフロー
Bさんがバックアップより前のバージョンのＸＸプログラムを
上書きし元に戻す
・
・
リリース手順書のレビュー
作成したリリース手順書を関係者でレビューすることによって、作業漏れの確認になる。当日の気持ちで確認しあうことでシミレーションにもなる。ここでのポイントはプロジェクトリーダの人はいかに、本番当日と同じ緊張感をメンバに伝えられるかどうかである
1日前迄にやること
プログラム修正の締切り
スケジュールがタイトなプロジェクトだと、修正作業をギリギリまでおこなわざるをえない。だが大小あがってくる修正箇所を対応しているとキリがなく、いつまでたってもリリースができない状態になってしまう(※要は、キリがないということである)。それはお客さん自社ともに困るはずなので、あらかじめお客さんに修正受付けの時間を決めておき、了承をもらっておく必要がある。
(参考例) 『○月○日の△時△分までに確認できた、 修正箇所については優先的に直しますが、 それ以外のものに関しては、リリース後対応させてください』
前もって出勤時間をリリース時に合わせる
Webアプリケーションのリリース時間は、世の中の人のアクセスが少ない時間帯を指定される場合が多い。(※新規オープンするサイトでは時間の指定はないが、既存のサイトをリニューアル、機能追加の場合)例えば、リリース時間がAM3:00～の場合、前の日に早く寝て、早く起きるという、平常時とは異なるサイクルをとらなければならない。そうなると体調を崩しやすい、寝不足になりやすいです。体調の状態はリリース作業に大きな影響を及ぼすので、以下のように前日から体内リズムを整える手法もある
(参考例) [12/02 03:00～08:00にリリースとした場合] 通常は09:00に出勤していた時間帯を 前日(12/01)の出勤時間を02:00～に変更し 深夜時間帯に体内リズムを整える
例のように03:00～のリリースだと前日より寝ずにリリースを迎えるという方法も可能。だが私の過去経験上、通常は22時位に仕事を終えていたリズムからさらに時間を延長することにより、集中力がもたない。尚、途中で仮眠を取るという方法もありだが後、数時間でリリースを迎えるという気持ちが高ぶってあまり寝れない経験があった。
前日から体内リズムをリリース時間に合わせて調整するという方法は、あくまでも私にとってベストであっただけだが、必ずしても万人に当てはまる手法かどうかはわからない。要は睡眠時間をきっちりとれ集中力が高められるかどうかがポイントだと思われる
リリース当日にやること
いかに平常心を保てれるか
前半にも書いたが、リリース時は非常に緊張するものだ。いつもとは違う自分がそこに存在しているといってよいだろう。特にネガティブシンキング傾向にある人がとくに緊張すると思われる。そこで心がけていただきたいのは、無事リリースしたときの成功イメージを頭の中で妄想してみる。それさえも緊張でイメージできない場合は、≪ 絶対に無事リリースする ≫、≪ 自分ならできる ≫と何回も頭の中でつぶやき、自己暗示にかけることも効果がある。後は、緊張状態にあると呼吸が浅くなりがちなので、深く深呼吸を3回やるだけでも、緊張がほぐれる。 可能ならばリリース作業前に、プロジェクトメンバ全員で実践できればベストである
リリース完了後1週間以内にやること
特別監視状態におく
無事リリースが完了した場合、これで終わりなのだが、Webアプリケーションの場合、まだ気を抜いてはいけない。ここまではあくまでもインターネットの大海原に1隻の船で港から出向したにすぎない。出向中で一番怖いのが、大波だ。大波＝アクセス集中が発生した場合、テスト環境で負荷テストを行って、サーバ、Webアプリケーションのアクセス処理スペックを把握していたとしていても、それ以上のアクセスが集中砲火した場合、サーバ、Webアプリケーションはあっという間にサービス不能に陥いる。そのために、この段階では、監視ツール(※MRTG、nagios...)などでアクセス処理状況に問題がないか毎日、定点監視を行うべきである。
また開発環境では発見できなかった、Bugが潜んでいる可能性もあるので、時間の経過とともに大きな問題になるまえに、DB、ログファイルに吐き出されたデータも定点確認することによりBugの早期発見が可能になる
リリース完了後2週間以内にやること
反省会を開く
この作業までたどりつけば、リリース作業も無事完了し、安定してサービスが展開されていると判断してよいだろう。ただし、反省すべき点というのは必ずなんらかあるはずである。それはあくまでもたまたま成功しただけかもしれない。次回のリリース作業では2度を起こさない、他の作業者が起こさない意味をこめて、反省会で情報を共有し、リリース作業の品質を高めるべきである
