なんかこの手の文章、散々書き散らかしてる気がしますが(苦笑
まぁしばらく、そうはいっても書き散らかしてみましょう(あ、言い切ったｗ)。
とりあえずプログラムが仕上がってきた、とします(そうしないと話が進まない)。
ンでもって、さらにとりあえず「正常系は真っ当に動いていた」とします。無論異常系も動いていると仮定しましょう。するんだってば。
「ならばOK！！」って言えるほどには甘くないのが世の中の常です。
ただ…それ以降の問題って、大抵「ある程度運用して」「状況的にシャレにならなくなってから」「一番発覚して欲しくないタイミング」で出てくるんですよね。
その辺のチェック項目を、思うがままにつれづれってみましょう。
機能拡張性確認の１
問：
(適当に１つチョイスして)この入力画面に１つ項目を追加するとどれくらいの時間と費用がかかりますか？ またプログラムは何カ所ほど修正をされますか？
回答：
一番いいのは、ユーザさんの情報を一つ増やすような項目ですね。今まで取得していなかった、例えば「一言」とか「あだ名」とかなんとか。
美しく組まれたプログラムの場合、DBテーブルのレイアウト変更でちょろり、プログラム修正を一箇所、程度で片付きます。
これが美しくないプログラムの場合、DBテーブルでなぜか複数箇所のレイアウト変更が伴い、プログラムの修正に至っては十数カ所とか二十数カ所とか。
後者の場合、得てして「ちょっとしたケアレスミス」が高確率で発生し、故に良い感じにトラブルが減りません。
機能拡張性確認の２
問：
新しい機能を付け足すのに、新しい機能「以外」の既存部分にはどこまでの修正が入りますか？
回答：
プログラムの基本はレゴブロックがごとき「ほかとの非依存性」にあります。
美しいプログラムの場合、大抵「設定ファイルをちょろりんと付け足して以上」程度。
美しくないと、既存プログラムに妙な修正が入り込みます。
で。これはバグの有無から費用の増減まであちこち関連したりします。
横断的関心事項への確認の１
問：
例えば、急遽「このサイトのアクセス全体に対して」「この機能全体に対して」「発行しているSQLを、Webサーバ側で一式」ログを取りたい、などの時に、どれくらいの工数、費用で対応ができますか？
回答：
正しく機能分割された、且つ、いわゆるMVCな作りの場合(つまり美しい設計の場合)。必要な「一箇所」が大抵あるので(或いは作るのが比較的容易なので)。ログの場合(ログの量とHDD容量との関係に考察は必要ですが)、比較的容易に仕込む事が出来ます。
美しくない設計の場合、この手の要素は「散らかるだけ散らかり倒す」ために、当然ながら網羅する事は容易な事ではなく、っつかぶっちゃけ作業漏れが、かなりの高確率で発生します。
うちではこれを「随所に関所」と呼称しますが。
これが完全に出来ている場合、例えば一般的なSQL-Injection脆弱性、XSS脆弱性などが「万が一」あったとしても、簡単に潰す事ができます(潰すべきロジックが一箇所にまとまってるわけですから)。
規模拡張性確認の０
問：
規模が拡張した時などにそなえて。システムリソース、プログラムの最適化などに対してきちんと意識を払っていますか？
また、それはどのあたりにどんな風に意識を払われてますか？
回答：
とりあえず、軽くジャブを(笑
どんな内容であれ、とりあえずそれなりに答えが返ってくればよし。
「具体例を出せ」に対していきなり口調が濁ったらアウト。
万が一「まってました」とばかりに立て板に水で語られ始めたら…あきらめて、満足いくまで騙り終わるまで聞いてあげてください(苦笑
規模拡張性確認の１
問：
Webサーバを横に広げたい時に、レイヤー７スイッチではなくてレイヤー４スイッチでロードバランシングが可能ですか？
回答：
これはMustではないのですが。とはいえ、レイヤ７スイッチとレイヤ４スイッチでは色々と、お値段から性能まで、楽しいくらいに開くのはまた当然のことでございます。っつかSSLを組み合わせた時点でもう一つ面倒なハードルが出ますしね。
ちゃんと「レイヤ４スイッチ」でも問題ない作りだと、ある程度までは「iptables」でお手軽なロードバランシングが可能なので、ぶっちゃけ「もの凄く廉価」にいけます。
人数が「ある程度」増える事が予想される状況であれば、重要な一考かと。
規模拡張性確認の２
問：
DBサーバが厳しくなった時に、クラスタリングなどをせずに負荷分散が可能ですか？
回答：
これもMustではないのですが。どうしても、クラスタリングの場合「ストレージを共有する」ために、わりと簡単に上限が見えてしまいます。
そうではなくて何らか別の方法で、もっとコストパフォーマンスのよい負荷分散ができるか否か、は、ある程度以上大規模なサイトを想定する場合、考慮してまったく損のないものになります。
ついでに、この辺を聞いておくと色々と面倒が少なかったりします。
具体的には「お役所のごときたらい回し」がある程度避けられます。
運用メンテ確認の１
問：
基本的なdaemon、ソフトウェアなどのバージョンが上がった際、必要に応じてinstall作業やその後の確認作業はしていただけますか？
回答：
まぁ…出来ないとか言われると色々と困りますよねぇ(苦笑
運用メンテ確認の２
問：
サーバが「落ちた」というタイミングではなくて、もう少し手前の状態で「そろそろ危なそうだ」みたいなサーバの状態を監視していただく事はできますか？
回答：
落ちてから「じゃぁ」とかされても困りますし。
とりあえず、uptimeとかロードアベレージとかnetstatとかvmstatとかその他の見方くらいは知ってる事が望ましいっていうか知らんでどうするよ？ って気がします。
…そのうちここに読み方とか書こうかなぁ？
あと。
監視の基本は「落ちたら知らせる」じゃなくて「生きている事を知らせる」ほうが確実です。
運用メンテ確認の３
問：
サーバの追加が必要になる場合の作業手順や必要なものなどは概ね把握されていますか？
回答：
とりあえず「用意しといてね(にっこり)」くらいのジャブを打っておくと、後々幸せになれますっていうか不幸にならずにすみます(笑
さて…以前書いたのも拾い集めなきゃｗ
