インフラ専門部隊が社内で他のチームと確実かつ早期に合意すべき事項
まだまだあるような気はしているが、とりあえず。
導入ソフトウェアの製品・バージョン・プラットフォーム(32bit/64bit)
開発で使用するソフトウェアのバージョンやプラットフォームは、本格的に開発が始まる前に決めておかないと変更が難しくなる。
サーバ・ホスト名・IPアドレス
結構、どんなサーバがいるのか、何台いるのか、周知されていないということがあります。『えー複数台いるなんて聞いてねぇえええええ』なんて叫ばれる実装をされないように注意しましょう。
- ホスト名と処理が密接に対応しているジョブとかがあると、ホスト名も自由に決められない場合もあります。
通信可否
インフラチームはセキュリティについても責任を負っているので不要な通信を通すつもりがさらさらない。よって必然的にアクセスはホワイトリスト方式で管理する。アプリケーションチームが実環境にデプロイした後、『通信ができない(涙』と泣きつき『そんな通信は知らん(キリッ』と対応するのも一興ではあるが、結局作業が増えるのはインフラチームなので、先手を打っておきたいところだ。
- アプリケーションチームは通信先とは通信できて当然だと思っていることが多いです。物理的接続？名前解決？ルーティング？ブロックされる？
OS上のユーザとグループ
『諸君がつかってよいユーザはこれだ(キリッ』と言うとき、インフラチームは世界を支配しているかのような満足を一時的に得られる。これを決めていないと『バッチを動かしているユーザとミドルウェアを動かしているユーザが違うのでファイル連携ができない、API連携が失敗する』などの阿鼻叫喚が連携時に発生する。またはrootや管理者権限を解放する憂き目にあい、世界の支配者は一転、勝手にシステムを変更されないか怯える敗者になる。
- 特に運用で使うユーザとかが見落とされる。
- ちょっと設定確認してもらうためだけの読み取り専用ユーザとかを容易しておくかで随分安心感が違う。
各チームで使用するファイル・ディレクトリの場所・容量
論理的な調整・変更がきくものと異なり、ディスクは『無い物は無い』の世界。不足したら対処が極めて難しいのだ。そして、置ける場所を制限しないと『このファイルはなんだ？』→『消してもいい？』→『絶対に大丈夫なのか？必要なファイルなんじゃないのか？』→時間経過により誰も消すことができないファイルが出来上がる。また、見かけ上容量が足りているのに、処理量が多いと一時ファイル・中間ファイルが増加してディスク圧迫して止まるとか。
- 大体どんなファイルやフォルダが必要になるか。
- 永続的な資産(アプリケーションやスクリプト)の配置先
- 動作上の中間ファイルの作成先
- 作業上の一時ファイルの作成先
- 永続的なデータの保存先(後述)
- ログ出力先
- その他ファイルやフォルダに関すること
- 削除してほしい一時ファイル・保持期間
- バックアップしてほしいファイル
- ログファイルのローテーション
消費するメモリ量
メモリも『無い物は無い』の世界。スワップ？そんなもの無いと思ってもらいたい。JavaならGCが頻発しない様な配慮も必要になるだろう。
- スタック領域を大量に消費するプログラムなんてものが、ulimitの制限で死亡することがあります。あってもソフトウェア制限がかかることもあるということ。
ディスク・データベースに保存するデータ量 (永続的なデータの保存先)
これが一番痛い『無い物は無い』の世界。バックアップ方式にも響くので、容量確定はお早めに。
- 開発中・運用中の機能追加でデータ量がある程度増える余地を想定しておくことも大事です。
ディスク・データベースに保存するデータの保持期間
5年保持なら5年で消してもらえるようにしましょう。でないと容量想定が崩壊します。追加は簡単なのだが、削除はとかく難しい。
監査が〜・法律で保持期間が〜・解約者の情報も再加入のため〜などなど、保持しまくりたくなる理由は多く、削除するための条件は厳しい。
下手をすると、他チーム『じゃ、このまま消すのやめよっかー（＾ω＾）』インフラチーム『・・・（＃＾ω＾）・・・』となりかねない。
稼働前に削除の十分な試験をしてもらおう。
