せめて、インフラ担当らしく

ITSM

おかしなものだ、OSのインストールなんて、ちょっと技術がある人ならできる。それが仕事になっている。最初はそう思った。そして、『この仕事では先はないだろう』とも思った。
実際にその作業は自動化されたり、ベンダー側での作業になったりして縮小している。人気のあるソフトウェアをOS側の機能として取り込むように、ベンダー側であれもこれも設定した状態で出荷します、というサービス展開は十分にあり得た。
ではなぜそれで満足できないのか、仕事が残るのか。何かが違うはずだ。『ちょっと技術がある人ならできる』ことと『ベンダー側であれもこれも設定した状態で出荷します』でできることと、我々ができることは。

何に顧客はお金を払っているのか。方法論(メソドロジー)にお金を払っている。そう思っている。出来上がったシステムをより『良いシステム』とする方法を知っていること、それを反映したシステムを作ってくれることを期待してお金を払っている。もしくは、『システム開発』というプロジェクト自体を乗り切るだけの技と体力があることを期待している。仮にそのメソドロジーを意識しないのであれば、それこそ単なる作業屋である。

  • とりあえずインストールしてちょっと検証してみた、という環境ではなく、システムの稼働期間中問題なく動き続けられる環境を期待している。4年目にログが溢れて止まるなんてことがない環境を期待している。
  • 問題予兆を検知できず、問題が発生してから難しい対処を迫られるなんてことがない環境を期待している。
  • 作った時点で動くだけでなく、システムの稼働期間中に発生する変更に対応できる柔軟性を残した環境を期待している。運用中にどんな変更が起こりがちか知っていてそれに対処できるようになっていることを期待している。

基本的にインフラは見えにくい性質が多い。『インストールして動いている』というのは見えやすいが、その他の性質・要件はなにかしら起こらないと見えてこないものがほとんどだ。壊れてみないとわからない・時間が経過してみないとわからない・利用者が増えないとわからない・事件(セキュリティ事故など)が起こらないとわからない、そんなものが多い。そのなかなかわからないものに対する仕込みをわかっている者としてしなければならない。

機能性

求められている機能が実現できていること。これができていないとそもそも稼働できない。

性能管理

主に応答時間・バッチ実行時間に関する要件。何を計って性能計測とするかを定義する。Web応答ならWebサーバに到着してからWebサーバがレスポンスを返すところまで(通信時間を除外する)、など明確にしておく。性能試験や運用開始後の情報収集を楽にするために、性能情報に関する情報は出力させておき、十分な期間収集しておく(容量と相談)。

キャパシティ管理

  • 主に同時接続・同時処理数・データ容量に関する要件。

信頼性

  • 堅牢性
  • 可用性
  • ITサービス継続
  • セキュリティ
  • トレーサビリティ
  • 耐障害弾力性
  • 長期連続稼働
    • ハウスキープ
    • 再起動運用

運用容易性

  • 自動化
  • 監視
  • 運用スケジュール (本当に24時間稼働させるのか？)
  • 運用体制
  • 定期のメンテナンス項目が明示されること

変化への対応力(柔軟性)

  • 構成管理・変更管理・リリース管理
拡張性

スケールアウト的な拡張・スケールアップ的な拡張それぞれについて、どこでそれが必要になるか想定しておく。また、『拡張する』という判断をするための基準を値で事前に決めておく(基本的にお金がかかる判断をするところなので、後づけするのがなかなか難しい。事前に決めておくとベンダー側・顧客側両方が幸せになりやすい。値の見直しぐらい平然と指示が・・・げほげほ)。拡張判断のための性能情報・キャパシティ情報を収集しておくことが必要。また、収集した情報を定期的に評価し、拡張要否を判断する機会を設けておく必要がある。

実際拡張する場合、運用への影響を少なく拡張できる方法を検討しておくこと。拡張で追加するものとすでに稼働しているものは最後のタイミングで接続するほうが作業は進めやすい。すでに稼働しているものを変更する方式は作業上かなり困難となる場合がある。稼働中の変更でも仕様・理論上問題ないとされているものでも、絶対大丈夫とは言えない世界。やらないで済む方法があるならそうしたい。実際作業する時は胃が痛むもの。

移行容易性

完全に新規でない場合にはデータ移行などが発生する。移行時は通常運用時と大きく異なるオペレーション(レコードの大量インサートなど)が行われるので、その場合に対応できる抜け道(常に使う訳ではないので、その時だけ穴をあけるとか)を用意しておく必要がある。抜け道の準備は容易であれば望ましく、構成をいろいろ変更するようなものは移行時点で実施する作業として望ましくない。