運用を考えよう

自分が書いたテックブログは、自分の趣味と実益を兼ねたネタを投下していたわけですが、今回初めて社内の立ち位置を若干でも意識した内容にしてみました。
だからと言って、情報セキュリティな話を書き出したらかなり分量書きそうな気配がしたので、「運用を考えよう」という話にした次第です。

運用でもそれなりの分量をかけそうですが…。

運用というものを考える

ファブリカコミュニケーションズでは車選びドットコムを始め、さまざまなWebサービスやsymphonyのような管理システムを作っています。しかし、どこにでもある話で「運用」についてはサービスの中の人たちも理解が浅いというか経験が少ない場合があります。

今回は「運用を考えよう」ということで、社内のサービス/システムを前提に「運用」を考えてみることにします。

運用
そのもののもつ機能を生かして用いること。活用。

デジタル大辞泉

いきなり自分なりの本質と思っていることを書いてしまいます。企業がさまざまなサービスやシステムを提供し、企業として成立するには、以下のことを循環させる必要があります。

• お客様の満足度を向上させ、よりサービス/システムを利用していただく
• その利用により、売上や利益を確保する
• 確保した利益で、さらにサービス/システムの改良を継続させる

そのため、私は「安定稼働する/させるための運用」が実は最重要なものだと位置づけています。

なぜなら、以下のようなことがあるからです。

• 「開発は一瞬、運用はサービスが死ぬまで続く」
• 「作ったら最後、サービスを墓場に持っていくまでサービスを維持する必要がある」
• 「サービスを墓場に持っていくと決断する時には、墓場に押し込む時のことも考えなければならない」

(使っていたサービスが突然止まるとどうなるかは、auユーザーさんは先月、身を持って体験させられたことと思います…。)

これら運用というものは、軍事的な面での「兵站(へいたん)」や「殿(しんがり)」という役割だと思っています。

ここをしっかり抑えないと上記の循環が止まりかねず、サービス/システムだけでなく企業としての死活問題でもあると考えています。また、上記の営業的側面以外にも、情報セキュリティ上のレベルを維持する/対策をすることも運用の一つとしておかないと、そういう面から足を掬われる…といったことが発生しかねません。サービス/システムの運用の品質を担保しながら効率を上げていくためには、やはり運用にも設計が必要と言えます。

「運用も設計するということ」とは

では、具体的に運用設計とはどんなことを考える必要があるのでしょうか？

1. 障害が発生した時に「なるはや」で復旧させるために手順を策定/準備する
2. 障害の予防・再発防止のための、分析・対策を行う枠組みを考慮する
3. タスク・ノウハウが属人化しないようにする
4. サービス/システム運用を効率化する/継続して行える仕組み・体制を用意する

と私は考えています。

はい、はっきり言って情報セキュリティの範囲も同じですね。(やっと役職らしい話になった…)

運用のゴールは「サービスが死ぬまで付き合う」なのですが、情報セキュリティは終わりがないだけで、やってることは変わらないと言えます。

最初はたどたどしくても、誰もができる状態になっていないと、サービスが不安定になってしまい悪循環な状況しか産みません。

さらに属人化してしまうことで、その人に負担がかかることになり、悪循環は加速してしまいます。

属人化ならまだしも、運用してくれる方々に余計な運用を押し付けるようなものならもってのほかです。

そんな悪循環にしない/ならないよう、運用も設計したほうが良いと結論づけられると思っています。

運用設計のための指針を考えてみる

では、具体的とまでは言えませんが、これをやっておけばなんとかなるという運用設計の基準的なものを並べてみます。

なおDevOpsやSREといった運用だけでなく、この業界に首をツッコんで(検閲)年で培ったサービス/システムを動かし続けるための経験則ですので、非機能要求グレードのようなものの考え方に、サービス上のトラッキング等に関連する話も盛り込んだものになっています。

1. 対象システムを見極める
   サービス/システムが提供するサービスの内容やターゲットとなる利用者、利用が特殊な状態にあったりアクセスが集中する日がある…などサービス/システムの使われ方を想定しましょう。
   サービス/システムの大小によらず、これを行わないと何をすべきかという話すらできません。
2. 物理的な運用管理対象を確定させる
   サーバーやネットワーク機器、ソフトウェアなど、運用管理する対象をリストアップしましょう。
3. 人的な運用体制を想定する
   人間がいないと始まらないし足りなかったら満足に運用できません。それどころかゾンビのようなサービスになるなど良いことは一つもありません。
   社内の運用体制や外部に委託するのであれば委託先もリストアップの対象に入れましょう。
4. 構成情報を作る
   サービス/システムにおけるサーバのスペック、ネットワーク図(論理/物理)や設定情報、ライセンスなどがあるソフトウェアなど、サービスに関わる物理的な管理対象の情報を洗い出します。
   当然アクセス数をトラッキングするシステムを入れておくことも重要です。
5. 監視の基準/仕様を決める
   監視や情報収集する項目を決めます。これはサービスインフラという話だけでなく、アクセス数やサービスの指標になる項目も基準/仕様として盛り込みましょう。
   その上で監視/トラッキングする方法を決め、リスト化しておきましょう。
6. 障害の重大度の基準の決定と基準に伴う対応方法やフローを決める
   障害時の連絡先・連絡方法、復旧対応終了条件、復旧連絡先・連絡方法、インシデントの管理方法などの手順を決めます。
   障害の重要度(サービス停止などの緊急事態や、サービスに影響しない一部のサーバ障害、単純なプログラムのバグ等)によって、レベル付けとそれぞれに応じたフローを作成すると良いでしょう。
7. 日常作業に何があるか決める
   前提として、バックアップや定期メンテナンス、プログラムのリリースやバッチ/ジョブの管理、ログ出力、マスタ更新、お客様のご利用状況の集計、メルマガの送信、スマートフォンアプリの通知など、スケジュールが決められる作業について、スケジュール（日次、週次、月次、年次）とその作業手順を洗い出し、まとめましょう。
   この部分については、実際には正常系と併せて異常系の作業をより多く洗い出すようにすることをおすすめします。これは日常作業における障害対応をしやすくするためです。これら異常系はスケジューリングできず、発生頻度も少ないことが多く、経験も積みにくいです。
   また優先度/重要度も併せて決めておくことで、担当者不在の際にヘルプを確実に行えるようにするだけでなく、一回スキップしてもOKなどとすることも可能です。
8. 外部からの影響を把握する
   システムの拡張やリプレース作業などサービスに関連するサーバーやネットワークの作業があれば手順を整えます。また、連携している外部システムに変更が生じた場合や、サービス/システムの対応に作業が必要であれば、手順や作業を整えます。
   見落としやすいことの一つに関連法規制等によるものがあります。サービスに関わる関連法規制の調査も踏まえて加えると良いでしょう。
9. 監視や対応するための仕組みを作る
   利用する監視ツールやそれらの仕組みや内容をまとめておきましょう。
   例えば電話サポートがあればトークスクリプトを準備する、メールサポートであればエラーメールが発生したりした場合の処理などもこの中の一つと考えて良いでしょう。
   また外部サービスに連携しているなどがあれば、連携方法やサポートの連絡先などもその中にまとめておくとその情報を探す手間も少なくなります。
10. セキュリティの意識を忘れない
    サービス/システムにおけるサーバーやネットワーク機器、ソフトウエアの脆弱性情報の収集方法、セキュリティパッチが公開された際の適用判断基準、適用頻度・方法をまとめます。
    アンチウイルスソフトなど、導入済み・必須となるセキュリティ関連製品(外部サービスも含める)の設定や運用方法についてもまとめます。
11. サービス/システムのアクセス数や稼働状況などの情報共有方法を決める
    サービス/システムにおける「計測できる数」を必要性とともに計測できるようにしておきましょう。
    サーバーやネットワーク機器のリソース情報の推移や、障害発生の状況(種類や頻度)が把握できるように障害対応を実施した内容一覧などを作ります。
    この時、情報を共有・評価・改善するための基準や情報を誰もが使いやすくするための出力内容を定義し一定の方法で提供することで、情報を必要とする方々の混乱を防ぎ、情報からサービス/システムの改善につなげることができるようになります。
12. 制限事項を明示する
    監視や障害対応を行うにあたっての制限事項(休日・深夜は対応を変えるなど)があれば、それを関係者に共有できるようにし、認識してもらいましょう。
    いわゆるSLA(Service Level Agreement/サービス品質保証)にあたるものと位置づけて良いものと言えます。
13. その他
    ここまでの項目に無いことでも「運用をするための」手順なども思いつく限り洗い出しまとめておきましょう。

ここまででもたっぷり書いてますが、書ききれなかったというのも事実で、さらにこれらが体系的に作られていく状態になるのが理想形と言えるでしょう。

障害対応の実際

今回のこの話の中で障害というのは「正しいと言えない可能性がある状態」のすべてを指します。
実際に「障害と指摘されたが違った」という話は何度もあるとは思いますが、これらもひとまとめで考え、情報セキュリティ的な言葉を借りると「リスクと事象」の範囲としています。

リスクと事象の意味はここでは割愛するとして、「リスクと事象が具現化した状態を障害」とし、設計はPDCAの考え方で進めていきますが、障害対応はそんなことを言っていられません。

障害をしっかりと状況を見極めて、どう対応するかの方法を考え、対応方法を決め、実行するといった流れでなければなりません。

概念的にはOODAループの考え方となり、PDCAのやり方をそのまま実行すれば、対応を計画している時点でサービスが止まります。

そんなことになってはいけないので、フレキシブルにこれらの概念を活用するようにしなければならないと思います。

実際の対応は障害に即したものでなければなりません。

調査や復旧した時の対応手順を対応時間とともに記録することが重要です。記録できる環境を整えましょう。
またこの時、再発防止に役立つ情報があることがわかっていれば併せて記録できる状態になると良いですし、その上で今までの運用に問題がなかったか見直しさらに良い方向にすることができます。

まとめらしきもの

運用は(企業ということではない)組織ごとに、個別で存在するとは思います。

ただ運用をやみくもにやっていても、非効率・非生産的となり、誰が関わっても良いことは一つもありません。せいぜい根性が鍛えられるというレベルです。

イマドキはそんな根性を鍛えるよりも、スマートにチームでやっていき、多くのアイデアで効率化をどんどん進める時代だと思っています。

そういうことからも、運用も設計し実践していくことで、誰もが携わることができ、サービス/システムを継続していくことにつながりそれが長期的な展望にもつながると、私は考えています。

弊社社内ができているかというとそういうことは言いません。道半ばです。
今後も色々改善されていくよう、がんばりましょう。