職業プログラマの休日出勤

職業プログラマによる日曜自宅プログラミングや思考実験の成果たち。リアル休日出勤が発生すると更新が滞りがちになる。記事の内容は個人の意見であり、所属している(いた)組織の意見ではない。

「運用でカバー」考察

友人との会話が「運用でカバー」の話題に至ったので、考えたことのメモを残しておく

世間で「運用でカバー」が悪手だと評価される理由の考察

  • 運用する側の負荷上昇度合いを考慮していないから
    • それどころか計測しようともしないケースも多々あるだろう
  • 運用する側に新たに発生する残業手当や休日出勤手当等の予算確保をしていないから
  • 運用する側に必要な手順などを共有していないから
  • 高リスク作業(ミスった時の被害が大きいもの)を手作業でさせるから

「運用でカバー」が必要とされる背景

  • 新システムの本番リリースが目前に迫ったタイミングで、機能的な不備が見つかって、修正が間に合わないとき
  • 要件が複雑すぎて、とてもシステム化できないとき
  • 発生頻度の低い業務
    • 言い換えれば、システムを開発するよりも、運用の人件費の方が安い場合、とも言える
  • 社外の人間との、非 machine-readable なデータのやり取りを回避するのが困難な場合(例:電話)

これらの要因を全て排除した事業運営など、よほど単純な事業内容でない限り不可能だろう。

筆者の経験則



正しい「運用でカバー」のために、やるべきこと

前述の「悪手」とされる理由の逆をやれば、正しい「運用でカバー」ができるはず。

  • 運用でカバーした場合の負荷を見積る
    • 運用開始後は実際に計測する
  • 負荷上昇分に見合った予算確保を実施する
    • 他の優先度の低い業務を放棄する、という手段も併せて検討する
  • 運用の手順等をきちんと設計する
  • 高リスク作業は、早急にシステム化するよう取り計らい、その姿勢を社内に見せつける
  • (これは悪手の理由とは無関係だけども)複雑な業務の一部分だけでもシステム化することには大きな価値があることもあるので、一気に100点満点を目指すのではなく、漸進的に得点を積み重ねていく。

おまけ

このTシャツ、欲しいw🦛

suzuri.jp