PHPのテクメモ

今回の障害に関するFAQが掲載された。Cloud9はそういうことをしなかったから、そういう意味ではマシな方。でも「データの復旧諦めた」ということなので、「マシ」と言っても1万円の借金のうち1円返済した程度でしかないのだが。

この期に及んでFAQをDBを使って構築するってのもどうかと思う。すごく重くてなかなか見れないし。とりあえず、データは復旧する見込みは皆無だと思うし、サポートとかしてくれるはずもないと思うので損害賠償の項目を列挙してみた。詳細は本家での確認が必要なのでお忘れなく（2012年6月25日11時くらいの時点での確認です）。

• 機会損失も含めて請求するが良いか。
  回答：誠に申し訳ございませんが、機会損失は損害賠償の対象とさせていただく予定はございません。

  日本語が変なのだが、要はショッピングサイトとかで、オープンしてれば品物が売れたのに、障害のせいで品物が売れなかった、ってことかな。ファーストサーバ側の意見としては伺っておく、というところか。今回の障害は重大な過失のような気がするので、裁判になったらそうはいかないとは思うが。

• 損害賠償請求の方法は。
  回答：現在検討中です。今しばらくお待ち願います。

  検討するのはやむを得ないかもしれないけれど、いつまでに告知するとかじゃないと被害者は困るんですけど。

• ファーストサーバで環境再構築を行ってほしい。
  回答：弊社では対応いたしかねます。ご要望にお応えすることができず、誠に申し訳ございません。

  さすがに無理だろうねー。でも小さい企業が頑張ってショッピングサイト構築して、高額の費用がかかっている場合、再度開発業者にお願いできるものなんだろうか。倒産かなぁ。

• 環境再構築にかかった費用は補償してくれるのか？。
  回答：補償いたします。ただし、誠に申し訳ございませんが、損害賠償の限度額の範囲での補償となります。

  損害賠償を払ってくれるってのはいちおうありがたいことではあるのだが、限度額の範囲ってのがねー（後述）。

• 賠償金額は？。
  回答：サービス利用契約約款に基づいて、お客様にサービスの対価としてお支払いただいた総額を限度額として、損害賠償させていただきます。

  これがよくわからなかったのでサポートに電話したんだけど、当然答え出ず。いちおう現在回答待ち（メールでくれってお願いした）。3万円のサービスを3年間使った場合、総額で108万なんだが、この場合で108万ってことなのかな。それとも月々の総額（この場合3万）のことなのかな。
  後者だと、1日分の人件費にもならないんだが、前者でもちょっと大きめのサイトなら足りないはず。エンタープライズ3のシリーズ31なら月額9,800円なわけで、その場合は36万円ってことでしょ。やっぱり全然足りないよね。

• SLAにおいて返金が明記されているが、それはどうなるのか。
  回答：このたびの障害の補償については、損害賠償という形で対応させていただくことになります。

  でも、これってどうなんだろ。SLA対象サービスを使っている人なら今月は無料になるので、それ以前の支払い分で賠償、ということになるのか。まぁ、どっちにしても微々たる金額なんだろう。

とりあえず、うちの場合は復旧作業費用ということで単価計算して費用を請求することになりそう。となれば、結局今まで使った費用全額返金で勘弁して、ってことになるんだろうなー。

なんかつかれる。

2012年6月20日夕方から発生しているファーストサーバの障害。データもバックアップも全部すっとんでしまった、史上最悪な感じなのだが、またしても被害にあうとは思わなかった。思えば昨年、NTT PC CommunicationsのCloud9の障害もひどかった。サーバダウンで、最終的にはたしか10日ほどして、なんとかデータを取り出せる状態になったものの、サービス自体が停止してしまうという大障害。サポートは「最終的にはレポートを作成して利用者に報告します」といっておきながら何もしなかった。きっとサポートは勤務時間がすぎれば「今日もつかれたねー」とか言ってビール飲んでるんだろうなーと思っていたのもはるか去年のこと。

そして惨事再び。Cloud9の場合はサービスが開始したばかりで実は被害者は少なかったのかもしれない。ファーストサーバはそうじゃない。しかも今回報道は「一部の・・・」となっているけれど実質「ほとんどの・・・」だろう。そしてデータが復旧される可能性もほぼなさげな感じ。いわゆる定番サービス、定番企業で、大手企業や官公庁も使っているわけで、もう、なんというかあまりにもお粗末すぎるこの結末。開いた口がふさがらなくて、サポートに電話で文句を言うも、途中でそれさえも嫌になる感じ。だって、1台のサーバに毎月3万円も払ってたんだもん。もうありえない・・・。

世の中でCloud9とファーストサーバの両方で被害にあった人ってどのくらいいるんだろう。あえて言うならAmazonの大障害やさくらの障害など、大きい障害を複数経験した人はどのくらいいるんだろう。あー。ため息。合掌。

TextWranglerというソフトウェア（Macの）、アイコンはかわいくないし、インターフェイスもそれほどカッコいいというわけではないが、Macで使えるフリーで高機能なテキストエディタの選択肢は少ないので、これを使っている。

初期状態では、シフトJISなファイルは文字化けしてしまう。じっくり見れば設定できるはずなんだろうけど、忙しいので放置していた（その間シフトJISなファイルは別のエディタで開いていた）。

今日少し時間があったので調べてみた。Googleで検索してもなかなか合致した結果が得られない。検索で引っかかる情報は、どうも古いバージョンの設定方法のようで、情報で明示された項目が見つからなかった。

で、以下の方法をトライしたらシフトJISなファイルも文字化けせず開くことができた。

Preferences – Text Encodingを開く
右下の「If a file’s encoding can’t be guessed, try:」の欄で、下の「＋」をクリックして「Japanese (Windows, DOS)」を追加し、それを一番上に配置した。

結果として文字化けせず表示させることができた。ちなみに「Japanese (Shift JIS X0213)」や「Japanese (Shift JIS)」でも大丈夫だった。微妙な違いがありそうだけど、ま、とりあえずOKってことで。

今や安価な共有レンタルサーバは星の数ほどある。うちでもいくつか使っているが、全てがよいサービスというわけではない。問題はこちら。

別にサービスの質が悪いとか、そういった不満はないけれど、お金の支払面の画面構成とか死ぬほどわかりにくい。下手にポイントとかプリペイドとか導入しては見たものの、利用者目線になってインターフェイスを考えなかった好例（悪例）とも言えるくらい使いにくい。

サービスとして提供されているレンタルサーバ、ドメイン、SSLは基本的に悪くないので、「惜しいなぁ」というのが正直な感想だ。

安いので使い続けるつもりではあるのだが・・・。いや、まぁ、ほんと使いにくい。マゾな方、お試しください。

ある作業でカラムの型としてDECIMAL型を選んだ。型の設定でDECIMAL(7,4)とすべきところをDECIMAL(3,4)としてしまっていたけどエラーにならなかった。当然そのままphpMyAdminに流すとエラー。

厳密なチェックがないっていうのは結構ありそうな感じかな。