社内ITシステムを構築・運用するのに最重要な3つのポイント

自社で使用するシステムを開発する、とする。

このとき迂闊にやっていると、気付いたら過去に構築したシステムのメンテナンスにばかり時間をとられ、新しいコードがぜんぜん書けていない、という状況に陥ることがある。
こうなると地獄だ。新規の興味深いコードを書くなんてとんでもない、という状態になる。メンテナンスコストを下げるためのコードすら書けなくて永遠に悲惨な撤退戦を繰り返すことになる。絶対に避けなくてはならない。

ということで、自分が心掛けていることをざっと書く。

全く手を入れずに動き続ける状態を最初に作る

もちろんシステムというものは生き物なので、ある程度のメンテナンスコストが必要になる。特に会社というものは生き物なのでシステム周囲の環境は常に変化する可能性がある。データ連携している別のシステムの仕様が変われば、当然そのデータを利用する側も対応しなければならない*1。

ということで、システムにはある程度の確率で、不可避なメンテナンスコストというものが発生することは覚悟する。それを理解した上で、普段の何の仕様変更もない日常においては、何らかのメンテナンス作業を要求することは絶対にしてはならない、と思おう。

何か作業をしなければ正常に動かないシステムは、その時点で既に正常ではない。毎日何かしないといけないならジョブスケジューラにやらせる。ある程度の確率で起きるイレギュラーな事態についても、比較的高い確率で起きるなら自動的に対処できるようにするべきだ。

定期的な手作業は複数システムのローンチを経て、最終的に手のつけられないレベルに増大する。蟻の一穴という言葉がある。例外を許してはならない。

メンテナンス時にダウンタイムを作らない

メンテナンス作業が必要なことはある。どうしてもある。データ量の増大にともなう稼動サーバの変更、データ連携先の変更、言語ランタイムやミドルウェアのバージョンアップ、あれやこれや。

それぞれの作業の難易度はもちろんいろいろだろう。しかし可能な限り、ダウンタイムをとってはいけない。あらゆる作業はダウンタイムをゼロで行う、そのくらいの覚悟でやるのが望ましい*2。

社内システムに限らないが、各種ITシステムの利用者は開発者が考えるよりもダウンタイムに敏感で、鈍感だ。と思う。この程度落ちてもいいだろうという意識で数分のサービス停止を何度も繰り返していると、システムのユーザは意外にもそのダウンタイムに気付いているし、そして簡単にサービス停止が常態化した状況に慣れてしまう。
こうなると、予想外の状況下においてシステムが停止している場合にも、それがなかなかユーザから報告されない、という状況を招く。早期に発見していればすぐ対処して数分で復旧できたのに、何日も気付かなかったばかりに復旧に数日以上も必要とする、ということは大いにありうる。

何か動かなかったとき、すぐにユーザに教えてもらえる、それが復旧への最短ルートだ。維持しよう。*3

動作不良には最優先で対処する

何かが正常に動いていない、と言われたとき、その問題には最優先で対処するべきだ。後回しにしてはいけない。そのシステムはもう捨てるという決断が行われているのでなければ。

各所の業務における、ある社内システムへの依存度というものを正確に測るのは極めて難しい。もちろんログを確認することで誰がいつアクセスをしたのかは分かる。しかしその動作がその人の業務にとってどのようなインパクトを持つのかについては、ログから推し量ることはできない。
もちろん個別にインタビューすれば分かることかもしれないが、全てのアクセスについてそのようなことは当然不可能だ。

システムが動作していないとき、それが誰のどのような業務にどの程度の影響を与えるか、あらためて確認している時間はない。開発者が大して重要でもないと考えたシステムが、社内のどこかの誰かにとってクリティカルになっていたりする。……というより、そんな状況にもなっていないようなシステムなら最初から作らなければよいのだ。

なので、動作不良が起きているとき、それは社内の誰かの業務にとってクリティカルな問題になっている、ということを前提に行動する必要がある。止むに止まれぬ事情があって即座に復旧できない場合、最低限どこかに時間的な見通しについて示しておかなければならない*4。

まとめ

書いてみたら当たり前のことすぎた。しかし何度でも繰り返す重要性があると思ったので、そのままポストする。

*1:余談だが、データ連携時のフォーマットがどう変わってもいいように予め作り込んでおこう！ という手法は愚の骨頂で全体の開発コストを異常に押し上げる上に使われていないコードを大量に残すことでメンテナンスコストまで激増させる。絶対に避けるべき。

*2:もちろんリスクの大きい作業を行うとき、その内容とリスク、何かあった時の影響範囲について事前に関係者に知らせておくのは最低限必要な作業のうちのひとつだ。ダウンタイムをゼロにする覚悟でいるからといって、その種の行動を怠ってよいということではない。あたりまえにやるべきことだ。

*3:もちろんシステムが正常に動作しているかの監視をきちんとやる、ということが重要なのは言うまでもない。しかしビジネスへの影響が直接的な形では見えない社内システムにそこまで厳密かつ正確な監視設定を必ず行えるところは少ないのではないかと思う。またデータが化けている、みたいな問題までシステム的に必ず拾うということは事実上不可能だと思う。

*4:もちろんだが、止むに止まれぬ事情とは、自分のエディタの中にある未コミットのコードのことは含まない。