障害発生！さぁどうする？

障害が発生するとＳＥさんってすぐに端末にかじりついて、ログ解析やプロセスの再起動などの作業に夢中になったりしません？（もちろん自分も経験あり）
障害の内容を把握する、システムの早い復旧を行うのはSEの大切な仕事なんで否定はしないですけどね。

実は、大多数の人にとって障害の原因なんて、ＳＥ本人が考えるほど意外なほどどうでもいいことです。（障害復旧後に作成する報告書なんて誰も見てなかったりして）

まずはアナウンス

大切なのは、障害のアウトラインが分かった段階で、外に向かって情報提供してあげることかもしれません。

• 被害の範囲（FAX受注は問題ないが、Web受注は使えませんとか）
• 被害の重大度（午前中に入力した伝票が全て消えましたとか。そりゃ大変だ）
• 復旧までの見込時間（あと30分でWeb閲覧はできるけど、メール復旧までは1時間かかるとか）

その時「JVMのGCか…」とか意味不明な専門用語使っちゃダメですよ(^^;

少なくとも何も情報がないと、システムを使ってるオペレータはシステムを使っていいんだか悪いんだか分からない。
もっと大きなシステムになると、

• 「システム使えねぇ！」って問合せを受けるサポート窓口
• 顧客に対して、早くお詫び連絡をしたい営業

など、外に向かって告知をしなくてはいけない人達がとにかく情報を欲しているはず。

もしかするとそんな皆さんは少し怒ってるかもしれないけど、堂々と情報提供してみましょう。

障害対応に燃えろ！

普段は縁の下の力持ちとして、深夜や大型連休に人目につかず頑張っているＳＥさんですが、障害対応はそんなＳＥの一番の見せ場！（いや、そんな格好いいもんじゃないな…）
そんな時に、実際対応は誰かに任せて、全体的な状況を把握して的確に情報提供をしてあげられると「デキるＳＥ」としておいしいとこ取り出来るチャンスですぞ。

これ普通の人にとっては「当たり前だ！」って思われるかもしれないんですが、草さえも食べない超草食系揃いのシステム屋さん達にとって、こういう外向きアクションは苦手なんですって…
わかってあげてくださいね(^^;

WindowsでWebサーバーを公開しておられるあるお客さんが、CMSを導入するとのことでPHPとPostgreSQLの設定を行うことになって、ものすごくハマってしまったので、同じことで困るかもしれない人のために情報を残しておきます。
問題が起こった環境は以下のような感じ
・Windows Server 2003
・PostgreSQL 8.4.0
・PHP5.2.10
インストールは普通にうまくいって、PHPも単体では動いていることを確認。
でも、どうやってもPHPからPostgreSQLに接続ができない。
pg_connectメソッドで、以下のようなエラーが
Fatal error: Call to undefined function pg_connect() in…
しかも、phpinfoの情報にもPostgreSQLのpgsqlブロックが表示されてないみたい？
ちゃんと、php.iniファイルの、「extension=php_pgsql.dll」も確認したし、もちろんhttpdの再起動もしたし…
それでもやっぱりエラーは消えないし…

お客さん、そのDLL壊れてますよ！

いろいろと調べてみると、どうやらPostgreSQLライブラリ「php_pgsql.dll」が怪しい感じ。
どうやら、Windows版のPHP5.2.6以降のバイナリに含まれる php_pgsql.dll は壊れている？
念のためチェックしてみると、php_pgsql.dll のファイルサイズは97kb。
どうやらビンゴのようで(-_-;)

php_pgsql.dllを入れ替える

とりあえずは、古いバージョンのWindows版PHPに含まれるphp_pgsql.dll と交換する必要があるらいしいので、http://www.php.net/releases/から、PHP5.2.5のWindows binaryをダウンロード。
解凍して、extディレクトリの中のphp_pgsql.dll を見てみると、ファイルサイズは165KB。
5.2.10の97KBと全然違いますやん。
で、PHP5.2.10のextディレクトリにあるphp_pgsql.dll を5.2.5のものに置き換えてみると…
すんなりつながりました。
え～、PHPのWindows binaryのバグ！？
PHP5.2.5～5.2.10まで、ずーっとバグったまま？
とりあえず、Windows + PHP + PostgreSQLの環境では、有名な話らしいんで、すぐに情報が見つかって助かりました。
【追記】
コメントにて、もっとスマートな解決方法を教えて頂きましたので、以下リンクしておきます。
PHP、Windows+PHP5.2.6以降でPostgreSQLに接続できない

Six Apartから、ブログエンジンMovable Type 5が発表されたところですが、このブログはやっと3から4にバージョンアップしたという話です。
そもそもの発端は、もう4年間ほどMovable Typeでこのブログを運営していたサーバーが、近頃やたらに遅いんでちょっとレスポンスの向上のために、サーバー引越をしようとしたのが目的。
で、どうせサーバー引越するなら、バージョンもあまりに古い3から4に上げてしまおうと思ったわけです。
とりあえずサーバーが新旧の2台あるんで、まずは新サーバーをじっくり準備することに。
作業端末のhostsファイルに、「blog.itoy.jp」として新サーバーのIPアドレスを登録。
なんとなく動作確認ができれから、DNSサーバーの設定を変更して、新サーバーのIPを登録する作戦です。

バージョンアップの手順

Movable Typeの場合（まぁほどんどのCMSはそうですが）、とにかくデータベースと画像ファイル群があればなんとかなる！

とはいえ、
１）バックアップ（旧サーバー作業）
まずは、設定ファイルから静的なファイルから何から何まで全てFTPにてローカル端末にダウンロード。
もしデータベースにBerkeleyDBやSQLiteを使っているなら、このタイミングでデータベースのファイルもいっしょにバックアップをとってしまいましょう。
※ちなみに私はSQLite使ってました。
２）SQLiteからMySQLに移行（旧サーバー作業）
もしかしたら、パフォーマンスが変わるのか？と
今回、データベースをSQLiteからMySQLに変更することを決断。
そんな時には、
MT Database Converter
がすごく重宝。
管理画面からパラメータを与えるだけで、あとは移行ツールが一気に変換してくれます。
３）MySQLデータベースのバックアップ（旧サーバー作業）
変換ツールが作ってくれたMySQLのデータベースを、mysqldumpコマンドにてデータベースを抜き取ります。
４）MySQLデータベースのインポート（新サーバー）
上（３）でエクスポートしたファイルを、新サーバーでまるごと取り込み。
５）Movable Type4のインストール（新サーバー）
MT4のモジュールを全て新サーバーにアップし、旧サーバーから持ってきた
・mt-config.cgi
・画像等のアップロードしたファイル
を新サーバーに配置
※私の場合は、mt-config.cgiのアップロード前にSQLiteからMySQLに設定変更しました
６）アップグレードの開始（新サーバー）
新サーバーのmt.cgiをブラウザから呼び出して、あとはお任せでアップグレード
７）テンプレートの修正（新サーバー）
ヘッダー、最近のコメント、プロフィールなどブロック化していたテンプレートの絶対パスが変わってしまったので手動でテンプレートを修正
８）再構築（新サーバー）
・「全てのファイル」の再構築を実施
・スタイルシート等の自動で再構築されないテンプレートを手動で構築
みたいな感じでした。
思ったより簡単。
あとは、QRコードのQRyも引越しさせたいなぁ…

「このシステムって、最後にバックアップをしたのいつなんやろ…？」
　財務…2008年6月12日（ただしバックアップは見たことない独自形式）
　顧客…2006年10月21日（一年半も前や…）
　売上…2008年6月12日（ただし一部のマスタや履歴データのバックアップは無し）
　在庫…2008年6月12日（ただし一部のマスタや履歴データのバックアップは無し）
財務は復旧不可能かもしれへんし、顧客は1年半前にさかのぼってしまう～、売上と在庫は中途半端なデータになってしまいまそうや…
◎平謝り
とりあえずは、まずは出社してきたばかりのクライアントの取締役にお詫びと報告に。
「私の不注意によるデータベース消失によって、大損害を与えてしまうかもしれません。
最悪の場合は6ヶ月分の経理伝票を入力し直し、顧客データは1年半分の情報を再入力する必要があります。本当に申し訳ありません」
はっきり言って私は謝罪しながら、損害賠償さえ覚悟してました。
そこでその取締役の言葉。
「ドンQさんが信用できる人間なんはよう分かりました。
これまでいろいろなＳＥがミスしては、よう分からんカタカナ言葉を使って責任逃れをしてたけど、自分の責任やと正面から謝ってきてくれたんはうれしかったです。
実はドンQさんが誤魔化しの説明をするようなら、徹底的に責任を追求したろうと思ってました。
誰にもで失敗はあるもんや。
とりあえず可能な限りの復旧をしてくれたら、それ以上は何も追求する気はないです。」
私は、久々に泣きそうになりました。
クライアントさんは高額な商品の仕入れをやって在庫を大量に抱える商売なんで、財務データが無くなってキャッシュフローが分からなくなるのは致命的なはず。
5月末時点で全店の実棚卸しをした在庫データが無くなってしまうことは、中間決算ができなくなることを意味するはず。
◎結末
結果的には、メーカーのフィールドサービス（早い話が修理屋さん）が来て、ディスクアレイボードを強制的にオンラインにして、リビルドする事によって何とか増設ディスクは復旧し、データベースも不整合から回復して一件のデータも消失せずに済んだのでした(^-^)
その修理屋さんが帰るのを見届けてから、取締役とがっちり両手で握手。
とりあえずは予定よりも4時間遅れたものの、夜8時半頃に無事に新サーバーの稼動に至ったのでした。
そして、帰り間際の取締役の一言。
「ドンQさん、これからもどうか末永くよろしくお願いしますわ。」
その数分後、私は泣きながら駅まで歩いていたのでしたσ(^◇^;)
そーいえば、朝ごはん食べたきり何も食べてへんかったなぁ。そりゃ手も心も震えるわけですわ(^^;)
最後に。
すんません。ものすごい自慢話で(ーー;)
あと電源関係の部分に限らずサーバー周りのものを動かす時には可能であれば電源OFFです。

で、そんなプログラマーの方をピンポイントで救済するサービスがこちら
SQLinForm
お～なんて地味な。
しかしながら、なんてシブいツボを押さえたサービスなんでしょー。
たとえば、こんなSQL文
SELECT M.StaffCode,M.StaffName,M.BranchCode,COUNT(S.OrderNumber) SalesCount,SUM(S.Sales) SalesTotal,TO_CHAR(S.SalesDate,’YYYY/MM/DD’) RecentDate,LS.LastYearFROM Staff M ,Sales S ,(SELECT SUM(Sales) LastYear FROM Sales WHERE SalesDate < 2007/10/01) LS WHERE M.StaffCode = S.StaffCode (+) AND M.StaffCode = LS.StaffCode

これが、このサービスを使うとこんなに読みやすく↓
SELECT M.StaffCode,
　　　　　　M.StaffName,
　　　　　　M.BranchCode,
　　　　　　COUNT(S.OrderNumber) SalesCount,
　　　　　　SUM(S.Sales) SalesTotal,
　　　　　　TO_CHAR(S.SalesDate,’YYYY/MM/DD’) RecentDate,
　　　　　　LS.LastYearFROM Staff M ,
　　　　　　Sales S ,(SELECT SUM(Sales) LastYear FROM Sales WHERE SalesDate < 2007/10/01)
LS
WHERE M.StaffCode = S.StaffCode (+)
　　　AND M.StaffCode = LS.StaffCode

素晴らしいっ！！（ただし、副問合せの解釈はやや弱いか？）
以上、本日はマニアックなネタでしたm(_ _)m
【ネタ元】

SQL文をきれいにフォーマットしてくれる『SQL in Form』（popxpop）