「文殊概論/３：文殊の技術的構成」の編集履歴（バックアップ）一覧はこちら

文殊概論/３：文殊の技術的構成 - (2009/04/22 (水) 01:54:38) の１つ前との変更点

追加された行は緑色になります。

削除された行は赤色になります。

前章：[[文殊概論/２：アイドレス２と文殊]] 次章：[[文殊概論/４：設定上の文殊]]
----

*§３　文殊の技術的構成
　文殊はある意味「CGI」アプリケーションとも言えます。しかし、皆さんが想像する「CGI」という言葉の印象（掲示板とかチャットとか）とは随分隔たりもあるでしょう。そして、黒埼がほぼ一人で文殊を開発・運用し続けている事を、随分と凄い事のように思う方もいるようです。

　これには、ちゃんと仕掛けがあります。わかってる人にはしっかりバレてる程度のものです。

　それでは、文殊開発と運用の裏側について、しばらくアイドレスから離れ、技術的側面から説明していきましょう。

** 文殊の運用系
#blankimg(center,monju_deployment.png , width=600 , height=300)
#center(){図3.1：文殊システム配置図（クリックで別窓に表示）}

　図3.1は文殊のシステムをバックアップまで含めて示したものです。　Ｗｅｂサーバのみを「文殊」と見なしてもいいのですが、運用系も全て含めるとこれくらい広がります。

・Webサーバ・maki.wanwan-empire.net：海外の業者である"RailsPlayground.com" と年間契約したサーバーを使っています。ドメイン名は私が別途取得したものを使い、これを業者のサーバの別名として適用しています。

・管理サーバ：私の自宅で常時動かしているサーバでWeb非公開。maki.wanwan-empire.net の死活監視とバックアップデータの定期取得を行っています。バックアップは１時間毎の１世代バックアップと、毎日の無制限世代バックアップの両方で行っています。ついでに Capistrano （デプロイ＝プログラムの更新用ツール）もこれに入れてます。

・バックアップ保管所：文殊のバックアップデータを保管しているWebサイト(http://www.geocities.jp/cw7_mirror/monju_backup/index.html)です。Geocitiesの無料アカウントを使っていますが、50メガバイトの容量制限がきついため、ちょくちょく過去のデータを手で消しながら使っています。（なんとかしたい・・・）

・ソースコードレポジトリ：文殊の開発用ソースコードを保持するサーバです。自宅の外において公開しているため、共同開発者のｏｄさんもアクセス・変更を加える事ができます。また、文殊を１から再構築する必要があった場合でも、このレポジトリにあるソースコードとバックアップ保管所のデータさえあれば可能です。

　では、それぞれの役割などについて、「開発」と「運用」という視点から、もう少し掘り下げてみましょう。

** 開発用ツール

**文殊開発の切り札：Ruby on Rails
　文殊は Ruby on Rails を使って開発しています。Ruby on Railsとは「Web アプリケーションフレームワーク」です。プログラマ以外の方にもある程度イメージしてもらえるよう説明するなら、Ruby on Rails＝「CGIプログラムのライブラリ」＋「開発の為の様々なツールの集合体」といったところです。有名なところが "Scaffold（＝足場）"生成機能で、データの定義さえあればCGIプログラムとしての定型的なコードは一発であらかた作ってくれたりします。足場だけあって味も素っ気もないCGI画面しか作れませんが、私は殆どこのままの状態で文殊の各種機能を作っています。（文殊の画面構成がひたすら地味な理由の半分はこのせい。もう半分は私の美的センスの無さ）。
　文殊の開発効率の高さは、全てこのRuby on Rails によるものだと言っても過言ではありません。これが がなかったら、私は文殊を作ろうとすら思わなかったでしょう

　Ruby on Rails のについての説明は本稿の範囲を超えます。Rails については良質な参考文献がたくさんありますので、そちらをご参照下さい。とりあえずWikipediaはこちら(http://ja.wikipedia.org/wiki/Ruby_on_Rails)。

**ソースコードの保存場所：Subversion
　Ruby on Railsを使って書いたコードはテストされ、テストが通るとSubversionリポジトリ（Repository＝貯蔵庫）に登録されます。Subversionには過去の登録履歴が全て登録されており、その度に変更点と変更事由も一緒に記録されます。このため、変なバグが入り込んでも、いつどんな理由でそれが入り込んだのか追跡し、その波及範囲についてもしっかり管理できます。バグは一匹見つけたら２０匹、ゴキブリみたいなもんです。こうしてしっかり追跡できるように手はずを整えるのは大事なことです。
　また、Subversionリポジトリを用意することで、共同開発者のｏｄさんも文殊のコードを改変することができます。文殊は一人で開発を始めましたが、いずれ一人では開発しきれなくなる事も想定していました。そのため、こうして最初から共同開発できる仕組みだけは整えていたのです。
　ちなみに SVNRepository.com は RailsPlayground.com の会社の別サービスで、サーバの契約をすると無料で使わせてくれます。（Google Code でもよかったんですけどね）

　余談ですが、最近は越前藩国HPのHTMLもSubversionで管理しています。修正履歴を保存できるってのは、何かと便利です。

**プログラムの配置：Capistrano
　Subversionにコードを登録した後、Webサーバにこれをアップロードしなければなりません。通常、CGIプログラムはFTPなどを使ってサーバに送るのですが、（経験者ならお分かりでしょうが）この手間は意外と面倒です。通常のCGIプログラムならファイル数は高々２０～３０といったところだと思いますが、文殊の場合は主要部分だけで1000を越えます（元々細かいファイルが多い構成なのです）。万が一に備え、前バージョンのフォルダを別名に変更して、新バージョンを正規のフォルダにアップロードして…などとやろうとすると、これまた結構な手間です。

　こういったデプロイ（＝配置）のために、私は"Capistrano"というツールを使っています。
　Capistranoは以下の手順をコマンド一発でやってくれます。

１）サーバの一時停止
２）別ディレクトリを作って、最新版プログラムをアップロード
３）Webサーバが最新版プログラムを利用するよう、リンクの張替え
４）サーバプロセスの再起動

　２）の手順によって、（上書きでなく）別ディレクトリに必ずコードを展開するため、「本番サーバにデプロイしてみたら動かなかった」場合でも、即座に前バージョンに戻すことができます。

　私が実際にデプロイする場合は、本番サーバと同じデータベースを使いつつ、別URLとなる「リハーサル環境」にまずアップロードして、動作チェックをしています。ここで引っかかるようならテスト・デバッグへ差し戻し。その間、文殊を停止する事はありません。デプロイの手間をCapistrano で自動化しているので、こういう2度手間も大して面倒を増やさずにできるわけです。

***問題追跡システム：Mantis　
　図の中には含めていませんが、問題追跡システムとして、ｏｄさん＠ヲチ藩国が管理している "Mantis”というものを使っています（http://t.im.etr.ac/my_view_page.php）。
　問題追跡システムとは、「バグ」や「開発案件」などを１件ごとに記録し、その進捗状態を管理・記録するためのツールです。

・「バグ」「開発案件」一つごとに、スレッド式掲示板のスレッドのようなものを一つを立てる。
・バグについて調査や終了報告などを行うたびに、スレッドにその経緯を追記する。
・案件１つの進捗状況ごとに「新規」「内容確認済み」「解決済み」といったステータスを保持し、適宜変更する。

　開発案件やバグをメモって忘れないように、またこれらの問題をｏｄさんとも共有しやすくするために利用しています。一人で開発するだけならToDoリストだけでもいいのですが、複数人で問題を共有していくなら、こういったものもあると便利です。

＃密かに法官・護民官業務でも応用できないかなと思ったりしてます。


**運用ツール

***バックアップの自動化と格納所への公開
　先ほどの図では、バックアップに関していくつかのcron ジョブ（＝自動化されたタスク）も含まれています。これは、文殊のデータのバックアップを自動化するために行っています。

　バックアップは以下の手順で行われています。

1) maki.wanwan-empire.net 上で文殊のバックアップファイルを作成。
2) 管理用サーバのcronジョブが maki.wanwan-empire.net 内に作られたバックアップファイルを手元にダウンロード。この時、ファイル名は日時を含んだ物に置き換える。
3) 黒埼の自宅のネットワークストレージにバックアップファイルをコピー
4)「バックアップ保管所」にバックアップファイルをアップロード。

***バックアップデータを公開する理由
　私がこうして各世代のバックアップデータをわざわざ公開していることには、理由があります。文殊管理人による不正なデータ改ざんを抑止するためです。

　現状、文殊管理人は文殊に対し、全てのデータを改竄できてしまいます。編集履歴すら自由に捏造できるのです。（いや、しませんけどね？）　文殊を管理する人員がアイドレスのプレイヤー以外であるなら、まだこれでもいいのでしょうが、私もまたアイドレスプレイヤーの一員であり、利害関係者です。
　本来、これは健全な管理体制とは言えません。

　しかし、「文殊管理人がデータを自由に変更できないことを保証する」のは困難です。文殊は私一人が管理しているので、どうとでも誤魔化せてしまうからです。それでも、私以外の管理者を入れないのは、技術的・保安的にとにかく面倒だからです（不可能ではないのでしょうが・・・）。

　そこで私は、「複数人の管理人がお互いを監視し続ける」複雑さを採用する代わりに、「過去のバックアップデータを常に公開し続ける」ことで、「過去にさかのぼってデータを改竄したと疑われる」可能性を極限しました。こうやって公開していれば、誰かがある時点でこれらをダウンロードする可能性が発生し、その可能性は私の改竄を抑止するのです。

　これは、文殊の扱うデータが全て公開できる性質のものだからこそ、取れる手段と言えます。閲覧するユーザに応じて隠すべきデータがあった場合、(少なくともその部分は）バックアップデータの公開という手段は使えません。

＃自分でも少々偏執的かなと、思う事もあります


***サーバーダウンへの対処
　文殊は稀に、いや時々、サーバーが止まってしまうことがあります。（ご迷惑をおかけしております）
　理由はバグの場合と過負荷の場合とがあります。

　バグには黒埼のうっかりが原因です。バグなら大抵はすぐに原因がわかるので修正も容易です。

　過負荷による停止の場合、問題は厄介です。
　以前はそれほどでもなかったのですが、アイドレス２のオフシーズンに入ったあたりからサーバダウンが頻発した時期がありました。
　この時の原因はPostgreSQLプロセスが過負荷で反応しなくなるというもので、こうなると私の権限ではどうしようもなく、サーバ業者に連絡してPostgreSQLプロセスを再起動してもらわないと直りません。（アメリカの業者だから英語でメール書いてます。大変。）

　文殊が利用しているサーバは共用サーバといって、１台のサーバを複数の利用者が同時に使っています（おそらく数十人レベル）。このため、他のユーザがWebサーバを酷使するような使い方をしている場合、私には対処方法がないのです。他のユーザの常識的運用を期待するほかありません。

　もちろん、一人で占有できるサーバを契約すれば解決するのですが……高いです。私はRailsPlayground.com の年間契約・１ヶ月あたり9ドルというサービスを使っていますが、同社の専用サーバプランで1ヶ月あたり$200とか言います。無理っ！


***サーバの死活監視:Nagios
　……というわけで、金が無いなら手間をかけるしかありません。「止まったらすぐ連絡」する監視体制が必要です。このため、最近になって "Nagios" を導入しました。
 現状、私の自宅のNagiosは文殊へ２分毎にアクセスし、その動作を確認しています。アクセス不能な事態が起きたら履歴を記録しつつ、私の携帯へメールを送るようにしています。

　このおかげで、深刻なサーバ障害にも即応できるようになりました。しかし、平日昼間に止まってしまった場合、夜になるまでどうしようもなかったりします。その時はすみません。本気ですみません。


**黒埼の日常

　では、典型的な黒埼のタスクについて、例を挙げて説明していきましょう。


・日中昼間：Nagiosから障害メールが届く。見てみると"Socket Timeout on 10 seconds"、文殊が１０秒以内に応答しなかった、との連絡。この場合はとりあえず放置。２分後に”Recovery"通知がくるようなら症状は軽度、すぐに回復したという事なので、緊急対処は必要なし。
　これが"500 Internal Server Error"だったら頭を抱える。可能なら昼休みに職場から対処し、それも無理ならとにかく残業回避に全力を注ぐ。


・仕事退けてメシ・フロなど済ませてから、メッセを起動。金庫番の人からオフラインメッセージなどが来ていない事を確認し、文殊の開発をはじめる。

・文殊の開発案件についてMantisで確認、コーディング、テスト。簡単なものなら１時間程度、難しいものでも１機能で２・３日かかりきれれば大体終わる。Rails万歳。

・レポジトリへの登録と文殊へのデプロイ。それぞれコマンド一発。

・金庫番から苦情：「なんか文殊の様子がおかしーですー！」黒埼の顔が青ざめる一瞬。事情を聞いた後、文殊のサーバへSSHログイン。動作ログを見てエラーを特定。

・デバッグ対応：ログをみれば大概の原因は一発で判明するので、これを直して再デプロイ。同じ条件で現象が再現しないことを確認し、金庫番へ更新を連絡。そちらでも現象再発なしを確認してもらって障害対処終了。

・Mantisに記録：バグと修正の内容、および対処に時間を記録する。本当は障害発生時点から記録すべきだが、大抵はバグ修正への速さを優先して後回しにしている。


　黒埼が文殊の開発において、各種の開発支援ツールを使っている様子がお分かりいただけたかと思います。


＃書いてて思ったが、私が対応不可能な場合は越前さんにやってもらう事も考えた方がいいかもなあ……。
ｰｰｰｰ
前章：[[文殊概論/２：アイドレス２と文殊]] 次章：[[文殊概論/４：設定上の文殊]]

前章：[[文殊概論/２：アイドレス２と文殊]] 次章：[[文殊概論/４：設定上の文殊]]
----

*§３　文殊の技術的構成
　文殊はある意味「CGI」アプリケーションとも言えます。しかし、皆さんが想像する「CGI」という言葉の印象（掲示板とかチャットとか）とは随分隔たりもあるでしょう。そして、黒埼がほぼ一人で文殊を開発・運用し続けている事を、随分と凄い事のように思う方もいるようです。

　これには、ちゃんと仕掛けがあります。わかってる人にはしっかりバレてる程度のものです。

　それでは、文殊開発と運用の裏側について、しばらくアイドレスから離れ、技術的側面から説明していきましょう。

** 文殊の運用系
#blankimg(center,monju_deployment.png , width=600 , height=300)
#center(){図3.1：文殊システム配置図（クリックで別窓に表示）}

　図3.1は文殊のシステムをバックアップまで含めて示したものです。　Ｗｅｂサーバのみを「文殊」と見なしてもいいのですが、運用系も全て含めるとこれくらい広がります。

・Webサーバ・maki.wanwan-empire.net：海外の業者である"RailsPlayground.com" と年間契約したサーバーを使っています。ドメイン名は私が別途取得したものを使い、これを業者のサーバの別名として適用しています。

・管理サーバ：私の自宅で常時動かしているサーバでWeb非公開。maki.wanwan-empire.net の死活監視とバックアップデータの定期取得を行っています。バックアップは１時間毎の１世代バックアップと、毎日の無制限世代バックアップの両方で行っています。ついでに Capistrano （デプロイ＝プログラムの更新用ツール）もこれに入れてます。

・バックアップ保管所：文殊のバックアップデータを保管しているWebサイト(http://www.geocities.jp/cw7_mirror/monju_backup/index.html)です。Geocitiesの無料アカウントを使っていますが、50メガバイトの容量制限がきついため、ちょくちょく過去のデータを手で消しながら使っています。（なんとかしたい・・・）

・ソースコードレポジトリ：文殊の開発用ソースコードを保持するサーバです。自宅の外において公開しているため、共同開発者のｏｄさんもアクセス・変更を加える事ができます。また、文殊を１から再構築する必要があった場合でも、このレポジトリにあるソースコードとバックアップ保管所のデータさえあれば可能です。

　では、それぞれの役割などについて、「開発」と「運用」という視点から、もう少し掘り下げてみましょう。

** 開発用ツール

**文殊開発の切り札：Ruby on Rails
　文殊は Ruby on Rails を使って開発しています。Ruby on Railsとは「Web アプリケーションフレームワーク」です。プログラマ以外の方にもある程度イメージしてもらえるよう説明するなら、Ruby on Rails＝「CGIプログラムのライブラリ」＋「開発の為の様々なツールの集合体」といったところです。有名なところが "Scaffold（＝足場）"生成機能で、データの定義さえあればCGIプログラムとしての定型的なコードは一発であらかた作ってくれたりします。足場だけあって味も素っ気もないCGI画面しか作れませんが、私は殆どこのままの状態で文殊の各種機能を作っています。（文殊の画面構成がひたすら地味な理由の半分はこのせい。もう半分は私の美的センスの無さ）。
　文殊の開発効率の高さは、全てこのRuby on Rails によるものだと言っても過言ではありません。これが がなかったら、私は文殊を作ろうとすら思わなかったでしょう

　Ruby on Rails のについての説明は本稿の範囲を超えます。Rails については良質な参考文献がたくさんありますので、そちらをご参照下さい。とりあえずWikipediaはこちら(http://ja.wikipedia.org/wiki/Ruby_on_Rails)。

**ソースコードの保存場所：Subversion
　Ruby on Railsを使って書いたコードはテストされ、テストが通るとSubversionリポジトリ（Repository＝貯蔵庫）に登録されます。Subversionには過去の登録履歴が全て登録されており、その度に変更点と変更事由も一緒に記録されます。このため、変なバグが入り込んでも、いつどんな理由でそれが入り込んだのか追跡し、その波及範囲についてもしっかり管理できます。バグは一匹見つけたら２０匹、ゴキブリみたいなもんです。こうしてしっかり追跡できるように手はずを整えるのは大事なことです。
　また、Subversionリポジトリを用意することで、共同開発者のｏｄさんも文殊のコードを改変することができます。文殊は一人で開発を始めましたが、いずれ一人では開発しきれなくなる事も想定していました。そのため、こうして最初から共同開発できる仕組みだけは整えていたのです。
　ちなみに SVNRepository.com は RailsPlayground.com の会社の別サービスで、サーバの契約をすると無料で使わせてくれます。（Google Code でもよかったんですけどね）

　余談ですが、最近は越前藩国HPのHTMLもSubversionで管理しています。修正履歴を保存できるってのは、何かと便利です。

**プログラムの配置：Capistrano
　Subversionにコードを登録した後、Webサーバにこれをアップロードしなければなりません。通常、CGIプログラムはFTPなどを使ってサーバに送るのですが、（経験者ならお分かりでしょうが）この手間は意外と面倒です。通常のCGIプログラムならファイル数は高々２０～３０といったところだと思いますが、文殊の場合は主要部分だけで1000を越えます（元々細かいファイルが多い構成なのです）。万が一に備え、前バージョンのフォルダを別名に変更して、新バージョンを正規のフォルダにアップロードして…などとやろうとすると、これまた結構な手間です。

　こういったデプロイ（＝配置）のために、私は"Capistrano"というツールを使っています。
　Capistranoは以下の手順をコマンド一発でやってくれます。

１）サーバの一時停止
２）別ディレクトリを作って、最新版プログラムをアップロード
３）Webサーバが最新版プログラムを利用するよう、リンクの張替え
４）サーバプロセスの再起動

　２）の手順によって、（上書きでなく）別ディレクトリに必ずコードを展開するため、「本番サーバにデプロイしてみたら動かなかった」場合でも、即座に前バージョンに戻すことができます。

　私が実際にデプロイする場合は、本番サーバと同じデータベースを使いつつ、別URLとなる「リハーサル環境」にまずアップロードして、動作チェックをしています。ここで引っかかるようならテスト・デバッグへ差し戻し。その間、文殊を停止する事はありません。デプロイの手間をCapistrano で自動化しているので、こういう2度手間も大して面倒を増やさずにできるわけです。

***問題追跡システム：Mantis　
　図の中には含めていませんが、問題追跡システムとして、ｏｄさん＠ヲチ藩国が管理している "Mantis”というものを使っています（http://t.im.etr.ac/my_view_page.php）。
　問題追跡システムとは、「バグ」や「開発案件」などを１件ごとに記録し、その進捗状態を管理・記録するためのツールです。

・「バグ」「開発案件」一つごとに、スレッド式掲示板のスレッドのようなものを一つを立てる。
・バグについて調査や終了報告などを行うたびに、スレッドにその経緯を追記する。
・案件１つの進捗状況ごとに「新規」「内容確認済み」「解決済み」といったステータスを保持し、適宜変更する。

　開発案件やバグをメモって忘れないように、またこれらの問題をｏｄさんとも共有しやすくするために利用しています。一人で開発するだけならToDoリストだけでもいいのですが、複数人で問題を共有していくなら、こういったものもあると便利です。

＃密かに法官・護民官業務でも応用できないかなと思ったりしてます。


**運用ツール

***バックアップの自動化と格納所への公開
　先ほどの図では、バックアップに関していくつかのcron ジョブ（＝自動化されたタスク）も含まれています。これは、文殊のデータのバックアップを自動化するために行っています。

　バックアップは以下の手順で行われています。

1) maki.wanwan-empire.net 上で文殊のバックアップファイルを作成。
2) 管理用サーバのcronジョブが maki.wanwan-empire.net 内に作られたバックアップファイルを手元にダウンロード。この時、ファイル名は日時を含んだ物に置き換える。
3) 黒埼の自宅のネットワークストレージにバックアップファイルをコピー
4)「バックアップ保管所」にバックアップファイルをアップロード。

***バックアップデータを公開する理由
　私がこうして各世代のバックアップデータをわざわざ公開していることには、理由があります。文殊管理人による不正なデータ改ざんを抑止するためです。

　現状、文殊管理人は文殊に対し、全てのデータを改竄できてしまいます。編集履歴すら自由に捏造できるのです。（いや、しませんけどね？）　文殊を管理する人員がアイドレスのプレイヤー以外であるなら、まだこれでもいいのでしょうが、私もまたアイドレスプレイヤーの一員であり、利害関係者です。
　本来、これは健全な管理体制とは言えません。

　しかし、「文殊管理人がデータを自由に変更できないことを保証する」のは困難です。文殊は私一人が管理しているので、どうとでも誤魔化せてしまうからです。それでも、私以外の管理者を入れないのは、技術的・保安的にとにかく面倒だからです（不可能ではないのでしょうが・・・）。

　そこで私は、「複数人の管理人がお互いを監視し続ける」複雑さを採用する代わりに、「過去のバックアップデータを常に公開し続ける」ことで、「過去にさかのぼってデータを改竄したと疑われる」可能性を極限しました。こうやって公開していれば、誰かがある時点でこれらをダウンロードする可能性が発生し、その可能性は私の改竄を抑止するのです。

　これは、文殊の扱うデータが全て公開できる性質のものだからこそ、取れる手段と言えます。閲覧するユーザに応じて隠すべきデータがあった場合、(少なくともその部分は）バックアップデータの公開という手段は使えません。

＃自分でも少々偏執的かなと、思う事もあります


***サーバーダウンへの対処
　文殊は稀に、いや時々、サーバーが止まってしまうことがあります。（ご迷惑をおかけしております）
　理由はバグの場合と過負荷の場合とがあります。

　バグには黒埼のうっかりが原因です。バグなら大抵はすぐに原因がわかるので修正も容易です。

　過負荷による停止の場合、問題は厄介です。
　以前はそれほどでもなかったのですが、アイドレス２のオフシーズンに入ったあたりからサーバダウンが頻発した時期がありました。
　この時の原因はPostgreSQLプロセスが過負荷で反応しなくなるというもので、こうなると私の権限ではどうしようもなく、サーバ業者に連絡してPostgreSQLプロセスを再起動してもらわないと直りません。（アメリカの業者だから英語でメール書いてます。大変。）

　文殊が利用しているサーバは共用サーバといって、１台のサーバを複数の利用者が同時に使っています（おそらく数十人レベル）。このため、他のユーザがWebサーバを酷使するような使い方をしている場合、私には対処方法がないのです。他のユーザの常識的運用を期待するほかありません。

　もちろん、一人で占有できるサーバを契約すれば解決するのですが……高いです。私はRailsPlayground.com の年間契約・１ヶ月あたり9ドルというサービスを使っていますが、同社の専用サーバプランで1ヶ月あたり$200とか言います。無理っ！


***サーバの死活監視:Nagios
　……というわけで、金が無いなら手間をかけるしかありません。「止まったらすぐ連絡」する監視体制が必要です。このため、最近になって "Nagios" を導入しました。
　現状、私の自宅のNagiosは文殊へ２分毎にアクセスし、その動作を確認しています。アクセス不能な事態が起きたら履歴を記録しつつ、私の携帯へメールを送るようにしています。

　このおかげで、深刻なサーバ障害にも即応できるようになりました。しかし、平日昼間に止まってしまった場合、夜になるまでどうしようもなかったりします。その時はすみません。本気ですみません。


**黒埼の日常

　では、典型的な黒埼のタスクについて、例を挙げて説明していきましょう。


・日中昼間：Nagiosから障害メールが届く。見てみると"Socket Timeout on 10 seconds"、文殊が１０秒以内に応答しなかった、との連絡。この場合はとりあえず放置。２分後に”Recovery"通知がくるようなら症状は軽度、すぐに回復したという事なので、緊急対処は必要なし。
　これが"500 Internal Server Error"だったら頭を抱える。可能なら昼休みに職場から対処し、それも無理ならとにかく残業回避に全力を注ぐ。


・仕事退けてメシ・フロなど済ませてから、メッセを起動。金庫番の人からオフラインメッセージなどが来ていない事を確認し、文殊の開発をはじめる。

・文殊の開発案件についてMantisで確認、コーディング、テスト。簡単なものなら１時間程度、難しいものでも１機能で２・３日かかりきれれば大体終わる。Rails万歳。

・レポジトリへの登録と文殊へのデプロイ。それぞれコマンド一発。

・金庫番から苦情：「なんか文殊の様子がおかしーですー！」黒埼の顔が青ざめる一瞬。事情を聞いた後、文殊のサーバへSSHログイン。動作ログを見てエラーを特定。

・デバッグ対応：ログをみれば大概の原因は一発で判明するので、これを直して再デプロイ。同じ条件で現象が再現しないことを確認し、金庫番へ更新を連絡。そちらでも現象再発なしを確認してもらって障害対処終了。

・Mantisに記録：バグと修正の内容、および対処に時間を記録する。本当は障害発生時点から記録すべきだが、大抵はバグ修正への速さを優先して後回しにしている。


　黒埼が文殊の開発において、各種の開発支援ツールを使っている様子がお分かりいただけたかと思います。


＃書いてて思ったが、私が対応不可能な場合は越前さんにやってもらう事も考えた方がいいかもなあ……。
ｰｰｰｰ
前章：[[文殊概論/２：アイドレス２と文殊]] 次章：[[文殊概論/４：設定上の文殊]]