最近、自分達が維持しているシステムで障害が発生した。俗にITの世界ではインシデントというのだけれど、まぁお客さんがシステムを使えなくなってしまう、という状況のこと。
もちろん、インシデントにもレベルがあって、システム的な問題が発生しても業務には影響が出ていないことが見きれれば、ある程度は自分たちのペースで対応を進めていくことができる。しかし、緊急性の高いトラブル、既にある機能が使えなくなっているとか、性能が著しく劣化するとか、そういった問題の場合は力の限りをインシデント対応にそそぐことになる。
と、今回は後者のパターンであったため、連日夜遅くまで働くことになった。もともと予定していた仕事は進めなければならず、そこに対して緊急の仕事が入れば当然そうなる。また、普段踏襲している安全なプロセスを通さずにスピーディな対応を求められることも多く、プレッシャーもかかる。だから、インシデント対応は苦しい。
一方で、不謹慎な話ではあるが、維持をやっている中で障害発生は面白いイベントだったりする。維持の仕事は基本的には短いスパンで同じようなことをひたすらぐるぐる回していくことが多く、飽きてくる。だから、障害が発生すると、新鮮なのだろう。また、否が応でも知らないことを勉強して、理解して、解決せざるを得ないため、成長に繋がったりする面白さもある。ただ、本来維持業務はインシデントを発生させないためにやっていたりもするので、そこには矛盾があるのだが。
私が障害対応が良いと感じるのは、やっぱりスピード感を持って仕事ができる点である。普段であれば、一ヶ月とかかけて失敗を防ぐために実に無駄とも思える複数のプロセスを経由した上で本番環境へリリース、となるのだが、障害対応時は緊急だから、という理由だけで、色んなプロセスをすっ飛ばすことができる。
ただ、そんな中でもデカい失敗はできないし、明らかに無茶なスピード感を求められると、苦しい。そんな分岐点の中にちょうど良い働き方があるのかなぁと思う。