ついにこのシリーズ最終章です。
最終章のテーマは「運用」。
リリースしたシステム、サービスをどのように運用すれば愛されるサービスになっていくのか。
「運用」は終わりがないものです。
果てしないからこそ、しっかりとした運用体制を作っておかなければいけません。
本題に入っていく前に、まずはこちらをご覧ください。
ファーストサーバ事件
2012年の6月20日、レンタルサーバー会社のファーストサーバは、大規模な顧客データの消失事故を引き起こしました。
その時に会社内部で何が起こっていたのかを取材した記事があったのでご紹介します。
詳しい記事の中身までは紹介しませんが、ぜひ一度読んでみてください。
当時の社内の様子を細かく話してくださっており、臨場感が半端ないです。
実際自社で起きたら...と思うとゾッとしましたね。。
事故の原因は、メールシステムの障害対策のため、対象サーバーに対してメンテナンスを行なう際に利用した更新プログラムに不具合があり、上記のサーバーのデータを削除してしまったというもの。
具体的な不具合は、メンテナンスの担当者が以前に使っていた更新プログラムを改変した際に、「対象外のサーバー群についてファイルの削除を行なうコマンド」を削除し忘れたことだ。
これにより、更新対象外のすべてのサーバーのデータがプライマリ／バックアップ共に削除された。
この事件を紐解いていくと、一番のポイントは開発と運用が一体化し、運用体制をしっかり確立していなかったことのようです。
第三者委員会から一番大きな問題として指摘されたのは、開発と運用の権限が分離されておらず、牽制のない業務フローになっていた点だという。
たとえば、システム変更作業が発生する時に、担当者が上長に報告し、スケジュール調整の後にそのまま実行していた。
つまり、いつ、誰が、なんの目的で変更作業を行なうのか、きちんと共有されていなかった。
そのため、事故の時になにが起こったのか、把握するだけでも多くの時間を費やしていた。
運用体制の不備により、データ消失の事故からさらに二次災害を引き起こしてしまった、とも記事中で紹介されています。
こういった運用体制の不備って、実は割と多くの会社が当てはまっていそうな気がします。
たまたまこの時はファーストサーバで起こりましたが、毎日どこかの会社では問題が起きているんじゃないかと思います。
もしこのような大事故が起こった時にあなたの会社はすぐに対処出来ますか？
少し「運用」の大切さを気づいて頂けたかと思います。
それでは本題に入っていきましょう！
目次
第1章 要件定義
第2章 設計
第3章 開発（実装）
第4章 テスト・検証
第5章 リリース
第6章 運用 ←今回はココ！
「運用」とは！？
企業や組織におけるIT活用は、業務システムなどを構築すれば終わりではありません。
その後に運用という重要な作業が待ち受けています。そして一般的な企業や組織におけるITコストの大半が、既存システムの維持のために費やされています。
サービスを生かすも殺すも運用次第だと思います。
運用次第で、せっかく良いサービスを開発出来たのに全く使われずにクローズしてしまう、というケースもあれば、逆に最初はそうでもなかったけどしっかりとした運用で次々に新しい機能をリリースして結果大当たりした、といったケースもあります。
つまり、リリースしたサービス・システムを継続的に利用してもらえるように行う、日々の改善活動を総称して「運用」と言います。
何から始めたら良いの？
一口に「運用」と言っても様々な運用があります。
何からしたら良いか分からないという方のために紹介したいのがITILです。
こちらのサイトを参考にまとめましたのでこちらも合わせてどうぞ！
5分で絶対に分かるITIL
ITIL
ITILを簡単に説明すると、
IT利用の先進企業におけるIT運用ノウハウを調査、これを体系化し、ガイドラインとしてまとめたもの
です。
このガイドラインは現在、英国商務省によって管理されており、英国出版局から8冊の書籍にまとめられて発行されています。
その中心となっているのは日常的な運用管理作業をテーマとした「サービスサポート」、そして中長期的な運用管理計画の策定を扱った「サービスデリバリ」です。
特に現場レベルの方々にも関係する「サービスサポート」はどのような流れで行うのか説明します。
サービスサポート
サービスサポートは以下の5つのプロセスに分かれます。
・インシデント管理
・問題管理
・変更管理
・リリース管理
・構成管理
サービスサポートはこれらを連携させた一連の活動であるとして、望ましい組織体制や対処手順を説明しています。
では、具体例に沿ってそれぞれどのようなことを管理するのか見ていきましょう。
あなたは大事な恋人とデートで居酒屋に入りました。
お腹も空いていたので早速料理を頼んでワクワクしながら待っていました。
ところがいつまで経っても料理は出てきません。
たまらず店員を呼びつけて文句を言いました。
「ちょっと、いつまで待たせる気？」
すると店員はこう答えました。
「申し訳ありません。大量の注文を厨房が捌ききれてなくて止まってしまっているんです。近くの店舗から応援を出してもらうのででもう少ししましたらスムーズにお料理出てきます！」
仕方なく待っていると程なくして料理が運ばれてきてその日は何事もなく終わりました。
後日、店の前を通ると求人募集の広告が貼ってありました。
あるあるですよね笑
ここで5つのプロセスに分解してみます。
インシデント管理
インシデントとは、顧客からのあらゆる問い合わせや障害、サービスのリクエストの総称です。インシデント管理はITサービスの停止を最小限に抑えることを最優先に活動します。たとえ根本原因は解明されなくともサービスが何とか使える状態に回復することを重視します。
上記の例でいうと、厨房が料理を捌ききれずにお客様を待たせてしまい、クレームを頂いてから緊急対応（近くの店舗から応援を出してもらう）したことまでがインシデント管理です。
問題管理
これはインシデントの根本原因を追究するだけでなく、将来起こりうるインシデントの可能性を未然に調査し、インシデントそのものの数を減少させることが主な目的です。問題を解決するために変更が必要である場合には、変更管理のプロセスに変更依頼を渡します。
上記の例でいうと、料理が捌ききれない原因が「人手不足」にあると突き止めることです。
変更管理
問題を解決するため、あるいは要件変更に対応するため、システムに変更をあらゆる面でコーディネートします。
上記の例でいうと、根本原因である人手不足の解消をするために「求人広告を出す」という結論を出すのがこのプロセスです。
リリース管理
変更管理で承認された変更依頼もとに実際の変更作業を行います。変更作業に当たっては計画から設計・構築、検証、切り戻し計画が行われます。
上記の例でいうと、変更管理のプロセスで出した解決策を実行するために求人広告を作成したり、どの広告媒体に掲載するかを決めたりして、実際に広告を出していきます。
構成管理
変更管理と密接に連携しながら、IT環境を構成するあらゆるハードウェアやソフトウェア、ドキュメントなどの構成アイテムが格納される構成管理データベース（CMDB）が最新・完全な状態に保たれていることを保障します。
上記の例で例えるのは難しいので、おそらくのイメージをお伝えすると、お店や求人に関する情報が最新かどうかをチェックするという感じです。お店の位置が変わった場合、住所や電話番号は最新のものになっているかどうか、などを更新しておく的な感じでしょうかね。。
ここで一つ注意して頂きたいのが、ITILはプロセスごとに実装すべきではないということです。
上記のプロセスを読んで頂ければ分かるように全てつながっており、どこかのプロセスだけ実装したからといって効果は出ません。
インシデント管理、問題管理、変更管理、リリース管理、構成管理といったプロセス毎に実装するのではなく、そのプロセスの中の活動レベルまで踏み込んで活用すべきものをピックアップして下さい。そして自社なりに最低限のPDCAサイクル「1周目」が回せるようにすることを考えるべきです。
まとめ
今回で「開発プロセスを分解してみた」シリーズ終了です！
基本の基だという情報が多かったかもしれませんが、エンジニアを始めて7ヶ月たった今、改めて一つ一つのプロセスを分解してみることで、自分の中での経験が整理されたように思います。
日頃、業務に追われていると中々自分の経験を振り返る機会が取れずにせっかくの経験が知識、スキルとして使えなくなってしまいます。
毎日、15分だけでも自分の経験を振り返って自分の中で体系化して再現性をもたせておくことが重要だと思いました！！
ここまで読んでくださったみなさまありがとうございました！！
引き続き宜しくお願いいたします！！
新卒未経験エンジニアの「運用」経験談
社内ツールを開発して早5ヶ月。
その間に、新規で2つの機能をリリースしました。
今のところ、大きな問題は起きていません。
使う規模が社内だけの小さなもので、機能もそんなに複雑なものがあるわけではないからだと思います笑
「運用」する上でユーザーの声をどれだけ聞くかはそのサービスの軸で決めるべきだと教えられました。
本当に必要な機能かどうか。
誰か一人が使いたいだけの機能ではないのか。
それを判断できるかどうかはそのサービスの定義をどこに置いているか、です。
まだまだ模索中です。。