運用保守って何してはるんです？

友人の子供が「オーケーぐるぐる」って言ってますが、
こちとらSiriで「ホンダのアシモ」で検索したら「恩田のあせも」を検索された衝撃は忘れられませんね。
最近は落ち着いてきましたが今年は酷暑が多く、恩田の皮膚が心配です。ささまるです。

稀に「運用保守費を開発費用にあてがうことはできないか？」というご要望があります。

結論から言うと出来ませんです。

開発はアウトプットが明確にあるためイメージしやすいですが、先方からしたら、運用保守は具体的な可視性の無い掛け捨て保険のようにも見えるだろうことも理解できます。
ので今回、ざっくりですが運用保守でやってること、というのを羅列してみます。

運用保守って何なの

そもそも運用保守って何よって話ですが、wiki大師匠によると

ソフトウェア保守

ソフトウェア工学において既存のソフトウェアを改良・最適化していくと共にバグを修正していくプロセスを意味する

ソフトウェア運用

コンピュータシステム等のシステムが停止することなく、利用顧客に対してつつがなくサービスを提供できるよう当該環境を維持管理すること

ついでにシステムとは「相互に影響を及ぼしあう要素から構成される、まとまりや仕組みの全体」だそうです。

ソフトウェアは基本、命令によって動作します。
結果0と1しかわからん機械に対して「こう動くんやでー（ﾖｼﾖｼ）」「こっちと通信するんじゃー（ﾎﾚﾎﾚ）」と指示、設定、パターン登録するのがプログラミングだったり構築だったりします。おおよそこのフェーズが開発と呼ばれるものになります。

でもって開発で作り上げた「システム」と呼ばれるものは、お客様に引き渡しされ運営され始めます。
そしたら、開発担当はお役目ごめん・・・ではなく運用保守フェーズには入ります。

で、何してんの？

お客様のシステム導入（アプリ含む）は、そもそもシステムを導入するのが目的じゃなくて、システムを導入して達成したいKPI、課題、目標、つまりは目的があるわけですよ。システムってワードがゲシュタルト崩壊しそう。そうした目的を達成するためには滞りなくシステムが稼働しており、日々変化する業務に可能な限り柔軟に対応する必要があります。

もちろん開発前のフェーズで色々ヒアリングして、どの部分でどこまで柔軟性を持っておくべきかなどは検討します。ですが、昨今ビジネスのスピードも速く、要件定義設計時点のビジネスの状態が、サービスイン後も同じとは限らないです。というか大抵の場合異なります。さらにはシステム内で利用している技術があっという間に旧世代化してしまう世の中です。
即ち、どんだけ頑張っても不都合は出ます。さらには不具合も出ます。不測の事象は発生します。ああ〜

そうした不測の事象に対応するのが運用保守です。

1. 緊急性のある改修
重要且つ緊急度の高い変更要件に対して、保守の範囲で対応することがあります。それが無いとサービスが滞るとか企業価値が下がるとかそういう類のもの。
もちろんボリュームや影響度によって、現実的に保守としては対応できない場合もあります。結構切り分け厳しかったりすることが多いですが、仮に保守範囲を超える場合は事前調整の上検収はあとにして対応は即時とすることもあります。

2.不具合の発見、通知、対応
ある案件ではサーバーでのプログラムエラーログをslackに飛ばしており、「あ、今何か動いた」を見つけやすくしてます。大抵のエラーはプログラム内でハンドリングされているので、中心的に見るのは予想外の何某です。外部連携先でのエラーに影響を受けている場合もあるので、そうした場合はお客様通知、調査の上、必要時は即時対応、本番適用まで行います。ボリュームや影響度、本質的であるかどうかなどによって、現実的に対応できない、または即時対応しないで改修時にまとめて対応したり、腰を据えて対応する時期を設けたりする場合もあります。不具合はプログラミングの範疇とは限らないため、頭を抱えることも多いです。

3.サーバー監視/メンテナンス
サーバー並びにプロセス監視、システムで利用しているモジュールアップデート、パッチの適用などを行います。上記、不具合発見でログ発見も監視の一環です。監視は主にCloudwatch、monitなどの監視・復旧ツールが中心となり、作業が頻繁に発生するものではないですが、再起動を伴うモジュールアップデートや設定変更の場合もあるのでタイミングは要相談です。構成変更や増強は原則入りません。

4. データ保守/メンテナンス
ログ、永続データのバックアップ管理などを行います。おおよその場合AWS大先生での作業です。ありがちなのが、業務上「データの区分が変わった」などのレベルでPG改修をともなわないデータ更新や、レアケースですがトリッキーな要求に対する手動データ更新とかも行います。

5.定期運用
よくあるのが月末にデータ抽出だとかレポート提出とかですね。おおよそ定期実行系はバッチ化したりするし、手動でやらざる得えないとしてもこうした「事前要件として成立しているもの」は正確には運用保守という範囲では無いっすね。
稀に突発的にデータ抽出の依頼がありますが、運用保守として対応する場合があります。レポートはそもそそも計算式やレイアウトなど調整がかかかりすぎるのであまり保守運用範囲ではお受けしません。

6.運営相談
ビジネスのスピードが速いと先に書きましたが、伴ってサービスの運営方法も途中で変わったりします。
Aの目的で作った機能だけど、工夫してBとして使ってるんだけどうまくいかない・・システムには関係ないんだけどサービスとしてはこんなことがしたいんだ・・・などなど様々ですがそうしたサービス運営上での困り事や相談などを承ります。現行システムでの対応可不可、改修の必要性など、話を受けながら想像できる必要があります。

心情的には、１つの役割をもった機能を、用途目的が全く異なる複数の役割で利用することは蕁麻疹が出る話ですが、ボリボリ掻き毟りながらも、緊急ならそれでいきましょう！でも次回もあるならそれ用の改修しましょう！とすることもあります。サービスインした後のシステムって、知らないうちにトリッキーに使われている場合もありますが、そういう場合は本質的に運営効率を下げている場合が多いので、代替可能な方法論があれば「うちのを使わない方が良い。そっちを使った方が良い」とお伝えすることもあります。

ざっと挙げただけでも、「既存のソフトウェアを改良・最適化していくと共にバグを修正していき、コンピュータシステム等のシステムが停止することなく、利用顧客に対してつつがなくサービスを提供できるようする」ためのポイントは多岐にわたります。運用保守ではこれらのどこで、いつ、何が起こるのか分からんという注意を払い、また発生必要時に調査、報告、対応、本番適用を行うフェーズです。

不測の事態にスタンばってると思っていただいても大差は無いと思います。不測であるからこそ、少なくとも弊社では提供しているシステム、ひいてはサービスを総合的に一定以上理解、把握している人間が担当しています。

運用保守が無いとどうなるのか

緊急重要性のある改修は出来ないし、不具合も放置、メンテもしなければプロセス落ちても知らん顔、データバックアップも無ければ、定期運用も何それおいしいの？状態。じゃあどうしようーと相談されても回答出来ません。

ベンダーによって内容/対象範囲はそもそも違うのが現実ですが「運用保守費用を開発費用にあてがう」ことは、少なくとも「稼働しているシステムの保護責任を放棄、およびシステムを介して提供されるサービス価値をないがしろにする」ことであり、「ただ作る」だけになります。仮に緊急重要性のある改修は無いし不具合も放置してよい、バックアップもパッチも不要じゃけん、と言われても、そもそも全く別のフェーズ・範囲のものであるため代替はできません。

ちなみに本稿では内容的に、なんとなく「運用」をシステム保守・運用として、「運営」をサービスの管理、計画実施運用っぽい感じで分けてますが、基本的にサービス全体に関わらせていただくことが多いので、おおよそソフトウェア、ミドルウェア、データ、インフラ、サービス関係諸々含めて「運用」って言う方が多いですね。あーゲシュタルト崩壊した。