運用保守とは、100 を継続すること
- 0 から 1 を作る
- 1 から 100 を作る
- 100 を継続する << ココ
運用とは何かを考える
サービスを使える状態にする事。英語だと operation
こんな経験ないだろうか。
「お金払ってるのに、まともに『応対』してくれない！
マニュアルもトリセツ(最近聞かない)もないなんておかしい！
こんなん使えんやろ！もういい、他のに変える！」
いわば『応対』が運用に近しい。もう少し砕くと次の 2 つ。
- 顧客がサービスを継続して使える状態にする事
- 提供者たちがサービスを把握している事
顧客がサービスを継続して使える状態にする事
モノは作ったら終わり、売って終わり、ではない。継続利用してもらって初めてモノになる。
きちんとお金をかける会社は、例えばコールセンターを用意する。
提供者たちがサービスを把握している事
仕様・操作方法をきちんと把握しているか、知見あるかどうか。
- 「その挙動が仕様なのか、不具合なのか」
- 「どういう操作をしたら NG なのか」
を把握できる組織(仕組み)が必要になる。無いとどうなるか。
顧客に「ごめんなさい」または「その操作はお控え頂きたいです、理由は...」の応答ができない。
保守とは何かを考える
サービスを魅力ある状態にする事。英語にすると maintenance
「このライブラリ、来年以降『メンテ』されないんだって。別のに変えようか」
そう、「メンテ」のこと。大きく 4 つある。
- 障碍対応
- (障碍 = 障害。読みは同じで、表記が違うだけです)
- 環境更新
- 機能追加・削除
- 諸改善
障碍対応(緊急度：高 / 重要度：高)
- クレーム応対
- 市場障碍(バグ対応)
- サーバーダウンからの復旧
- etc.
原因を突き止め、再発防止の為に恒久対応を実施する。恒久対応がすぐ難しいならば
早急に暫定対応を実施する。初動が遅いと、顧客減少に直結する。
環境更新(緊急度：高 / 重要度：低)
- フレームワーク、ライブラリの脆弱性対応
- 最新 OS への対応、サポート切れが近い OS の対応方針を立てる
- etc.
作った時の状態、デプロイした時の状態がいつまでも正しい状態ではない。
初動を早める必要性は場合によるが、放っておく期間の長さと、市場へのインパクトは比例する。
機能追加・削除(緊急度：低 / 重要度：高)
市場に出して初めて、顧客のリアクションから気づきを得られる。
- 実はこういう機能を作った方が良かったんじゃないか
- この機能要らなかった(利用頻度が極端に低いなど)
それぞれ整理してサービスをアップデートをする。
諸改善(緊急度：低 / 重要度：低)
- 性能向上(特定機能の実行時間短縮、ビルドマシン最新化、etc)
- 作業自動化(テスト、デプロイ作業、etc)
- etc.
どれだけ人・モノ・時間(カネ)をかけられるかでやる事、セクション(緊急度・重要度)は変わると思う。
(ここはプロジェクトによっていくらでも流動するだろう)
あとがき
突っ込んだ話は別記事に書く予定。時期は未定。
- 運用で大事なことは何か
- 保守で大事なことは何か
といった感じ。
モチベーション
運用保守でググってもピンとこない記事が多かったので、自分なりに書いた。