ワークフローサンプル: 「障害チケット」のステータス、自動的に社内共有される仕組

ココだけの話だが(?)、「システム障害対応」は盛り上がる(!!)

情報システム（コンピュータシステム）に『障害』はツキモノだ。一般の方からは「さぞや身も心も疲弊するのだろう」とか「タイヘンな仕事だね」などと思われがちだが、実はそうでもない。いざコトに当たっては、アドレナリンが分泌され、脳味噌は覚醒し、何故か分からないが、仮にそれが真夜中であったとしても一心不乱に障害の原因を探究する事ができるのだ。そして対応完了時にはスガスガしい気分になれる。意外と健康的な仕事だ。（もっとも、その直後に覇気を失う）

そして、こういった「非常事態」を共に乗り越えると、これまでの知識も整理され、また組織としてのチームワークも醸成される。技術鍛錬の観点でも意外と悪くない。（もちろん、その発生頻度が頻繁なモノであれば耐えられないのかも知れない。。。）

（改めて書いておくが、ココだけの話だ!!?）

以下の業務プロセス定義は、「障害チケット」（トラブルチケット）と呼ばれる緊急対応案件を管理するワークフローだ。障害チケットがオープンされれば関係者に一斉通知され、各対応者が指名される。役員や従業員の内で [データ閲覧権限] がある人は、リアルタイムに状況をモニタリングするだろう。（そして社内SNS機能では、「『断続的』って頻度は？」や「『一部のユーザ』って誰？」などの会話で盛り上がる）

なお、この業務プロセスの最終成果物は「事後レポート」だ。対応チームとWeb公開チーム、両方のチームでそれぞれに作成される。

[障害対応フロー]

[障害対応フロー：「1.障害チケットをオープンする」画面]

ちなみに、Questetra社もパッケージソフトウェア業（G情報通信業＞G39情報サービス業＞G3913）に分類される会社として、お客様に対し「クラウドコンピューティング環境」（SaaS）を提供している。つまり、いわゆる「クラウド事業者」に該当する。

利用者にとって「いつでも何処からでもコンピューティング環境を利用できる」と言うのは当たり前の要求にすら思える時代だ。しかし、目下のクラウド事業者にとって「24時間365日 (24/7)」の実現はナカナカきびしい状況にある。非常に多くの機器の様々なソフトが相互にやり取りをして初めて「動作している」とみなされる仕組みであり、不可抗力的に発生してしまう障害もある。（電力供給、通信回線、サーバ機物理障害…）。どうしても年に数度のシステム障害は発生してしまう。（Questetra のサービス稼働率とサービス障害ログ）

もっとも、、、、今日に至っては、仮想化技術が進化し、いわゆる「現場」へ急行しなければならない様なケースは無くなった。あるいはまた、設定作業の自動化技術も確立され、いわゆる「手作業ミスのリカバリ」と言う作業もほとんど無い。5年？、10年？、20年？、、、巨視的に見れば、いつの日かリーズナブルな原価で「24時間365日 (24/7)」を実現できるようになるのだろう。

PS
すでに余談でしかないが、障害原因の探究は地道な確認作業に始まる。誰にでもわかる様には説明できないが、つまるところ「情報システム」の各要素別に障害原因を見極めていく作業になる。しかし「要素」と言っても非常に多い。つまり「情報システム」の各要素は

A.通信ネットワーク群（他システムを含む）
B.ハードウェア群
C.ソフトウェア群
D.データ群

のいずれかに大別されるが、たとえば「C.ソフトウェア群」に分類される要素としても、「OS」と呼ばれるものから「オープンソースアプリ」と呼ばれるものまで、大小合わせると100や200といった数になってしまう。システム全体で「システム障害の原因」を考えれば、その要素の組み合わせの数だけのパターンだけある。どうしても勘と経験が必要になる作業だ。
（2012年7月の「うるう秒障害」の様に、社内の技術や知識だけでは如何ともしがたい障害もある）

＜データ項目一覧画面＞