XML
知って損はない！ Webアプリケーションのリリース時に気をつける事
3日前迄にやること
リリース時にやるべきこと(作業内容)を、記述したドキュメントを作成するのとしないのでは、雲泥の結果を生み出します。何回もいうようにリリース時にはどんなに肝っ玉が据わった人でも平常時以上の判断・能力を発揮することはできないので、頭をつかわずとも、リリース作業ができるように前もって手順をまとめておくためです。誰(Who)が何(What)を何時(When)にどう(How)すべきなのかを明確化することが大切です。後は、開発環境では問題なく動作しているプログラムも、本番環境だと動作しない(※ミドルウェアのバージョンや、サーバの設定が異なっている事により発生しやすい)ケースがあります。
ケースによっては巻き戻しフローも明記しておくこともあります。すでにサービスを開始しており、リニューアルや、機能追加の場合では、サービスを継続すること(※サービスを止めない)が第1だと思いますので、前のバージョンに巻き戻す事を巻き戻しと呼んでおりります。作業内容が決まば、作業完了時間が決まります。その時間完了時間から1時間以上オーバした場合、リリース作業を急遽取りやめ、巻き戻し作業に入るわけです
ケースによっては巻き戻しフローも明記しておくこともあります。すでにサービスを開始しており、リニューアルや、機能追加の場合では、サービスを継続すること(※サービスを止めない)が第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～の場合、前の日に早く寝て、早く起きるという、平常時とは異なるサイクルをとらなければなりません。そうなると体調を崩しやすい、寝不足になりやすいです。体調の状態はリリース作業に大きな影響を及ぼすので、以下のように前日から体内リズムを整える手法をとるのもありかと思います
例のように03:00～のリリースだと前日より寝ずにリリースを迎えるという方法も可能です。ですが私の過去経験上、通常は22時位に仕事を終えていたリズムからさらに時間を延長することにより、集中力がもちませんでした。尚、途中で仮眠を取るという方法もありですが、後数時間でリリースを迎えるという気持ちが高ぶってあまり寝れませんでした。
前日から体内リズムをリリース時間に合わせて調整するという方法は、あくまでも私にとってベストであっただけですので、必ずしても万人に当てはまる手法かどうかはわかりません。要は睡眠時間をきっちりとれ集中力が高められるかどうかがポイントだと思います
(参考例) [12/02 03:00～08:00にリリースとした場合] 通常は09:00に出勤していた時間帯を 前日(12/01)の出勤時間を02:00～に変更し 深夜時間帯に体内リズムを整える
前日から体内リズムをリリース時間に合わせて調整するという方法は、あくまでも私にとってベストであっただけですので、必ずしても万人に当てはまる手法かどうかはわかりません。要は睡眠時間をきっちりとれ集中力が高められるかどうかがポイントだと思います
リリース当日にやること
前半にも書きましたが、リリース時は非常に緊張するものです。いつもとは違う自分がそこに存在しているといってよいでしょう。特にネガティブシンキング傾向にある人がとくに緊張すると思います。そこで心がけていただきたいのは、無事リリースしたときの成功イメージを頭の中で妄想してみる。それさえも緊張でイメージできない場合は、≪ 絶対に無事リリースする ≫、≪ 自分ならできる ≫と何回も頭の中でつぶやき、自己暗示にかけることも効果があります。後は、緊張状態にあると呼吸が浅くなりがちなので、深く深呼吸を3回やるだけでも、緊張がほぐれます。
可能ならばリリース作業前に、プロジェクトメンバ全員で実践できればベストですね
可能ならばリリース作業前に、プロジェクトメンバ全員で実践できればベストですね
リリース完了後1週間以内にやること
無事リリースが完了した場合、これで終わりなのですが、Webアプリケーションの場合、まだ気を抜いてはいけません。ここまではあくまでもインターネットの大海原に1隻の船で港から出向したにすぎません。出向中で一番怖いのが、大波です。大波＝アクセス集中が発生した場合、テスト環境で負荷テストを行って、サーバ、Webアプリケーションのアクセス処理スペックを把握していたとしていても、それ以上のアクセスが集中砲火した場合、サーバ、Webアプリケーションはあっという間にサービス不能に陥ります。そのために、この段階では、監視ツール(※MRTG、nagios...)などでアクセス処理状況に問題がないか毎日、定点監視を行うべきです。
また開発環境では発見できなかった、Bugが潜んでいる可能性もあるので、時間の経過とともに大きな問題になるまえに、DB、ログファイルに吐き出されたデータも定点確認することによりBugの早期発見が可能になります
リリース完了後2週間以内にやること
この作業までたどりつけば、リリース作業も無事完了し、安定してサービスが展開されていると判断してよいでしょう。ただし、反省すべき点というのは必ずなんらかあるはずです。それはあくまでもたまたま成功しただけかもしれません。次回のリリース作業では2度を起こさない、他の作業者が起こさない意味をこめて、反省会で情報を共有し、リリース作業の品質を高めるべきです
