![エンタープライズIT [COLUMNS]](https://ent.iij.ad.jp/wp-content/themes/liquid-smart-child/img/logo.svg){kind=logo}
シェア
ポスト
ブックマーク複数のクラウドを組み合わせて利…
UOMって何？？開発者に聞いてみた（後編）「忙しい」システム運用管理の現場を変えたい！サービス開発への思い
セキュリティサービスのプリセールスとして、お客様のセキュリティ対策支援に長年にわたり従事。
現在はプロモーション活動を中心に担当。
執筆・監修者ページ／掲載記事：3件
＜若手マーケ和泉が行く！IIJサービスの”裏側”を聞いてみたシリーズ＞
IIJに最近入社した若手マーケティング担当の和泉。上司から「まずは各サービスの特長を学んでこい！」とのお達しがあり、IIJサービスの開発者を巡る旅が始まりました。
IIJに最近入社した若手マーケティング担当の和泉。上司から「まずは各サービスの特長を学んでこい！」とのお達しがあり、IIJサービスの開発者を巡る旅が始まりました。
前回は、システム運用の課題や現状について分かりました。
後編となる今回は、多忙な運用現場を改善する方法をIIJ社内での事例も含めて聞いてみました。
IIJの改善例をそのままサービス化
-
和泉 -
前回、IIJ自身の運用業務の効率化から生まれたシステムが運用管理サービス「UOM」と聞きました。サービスとしてリリースするまでの経緯を教えてください。
-
福原 -
IIJでは数多くのサービスやお客様システムを運用しています。そんな中、IIJ自身も障害対応やアウトソーシングに従事するサポートセンターが疲弊していて、「これを何とかしたい」というのがきっかけでした。
前回お話した運用担当者の課題と同じで、アウトソーシングビジネスの拡大に伴い運用対象は増えるものの、担当者を増やすことは難しい状況でした。このため、効率化を迫られていた、というのがきっかけです。
-
和泉 -
なるほど、IIJ自身の運用現場の課題を解決するところからスタート、ということですね。具体的にどのような業務の負荷が高かったのでしょうか？
-
福原 -
初めに取りかかったのは、圧倒的に時間がかかっている障害アラート処理の自動化ですね。お預かりしているシステムが多いので。
障害が発生すると障害チケットが作られるのですが、その対応のために、24時間365日体制でチケット管理画面に担当者が張り付く必要があり、人材の工面や障害対応頻度が課題となっていました。
-
和泉 -
それは大変ですね…。
-
福原 -
そこでまずは運用業務の整理の第一歩として、現状の分析からスタートしたのですが、調査をしてみるとなんとアラートのうち「約97%」が障害対応が不要なアラートだった、ということが分かってきました。
-
和泉 -
ほぼ全部に近い（笑）。
そもそも、いらないアラートってあるんですか！？
-
福原 -
残念ながら意外とあるんですよ（笑）。
例えば、定刻に届くようなものや、復旧アラートの確認だけで済んでしまうものなどがありますが、ほとんどが不要なアラートな印象ですね。
私自身、前職ではシステム運用を担当していて、まさにこの運用の「ツラさ」を現場担当として実感していました。
大量に届くアラートは分かりやすく言うと“迷惑メール”みたいなものです。このようにたくさんのスパムが届くと、重要なアラートが埋もれてしまう、というのもよくある話です。
やるべき対応を見極める
-
和泉 -
なるほど、大変さを実体験していたんですね。
-
福原 -
常にアラートに追われるという状況を改善するには、本当に対応すべきものを見極めていくことが大切だと考えていました。こうしたことから、何らかの条件で、大量のアラートを必要なものに絞ることが重要と考えました。
-
和泉 -
素朴な疑問で、いらないアラートをそもそも発生しないように、監視設定を調整したりできないのでしょうか？元から絶つように。
-
福原 -
すごくいい質問ですね。ですが、現実は結構難しいんです…。
システム開発時には運用まで考慮しきれず、運用が始まってから様々な実態や課題に直面する、というのがほとんどですね。
-
和泉 -
なるほど…出元は調整できないから、受け取る側で工夫する必要があると。
-
福原 -
そうなんです。このため、例えるならファイアウォールのように、必要なポートのみを開けるというアプローチで、アラートメールをフィルタリングする仕組みにしようと思いました。運用業界ではアラートをフィルタリングする、といった概念はあまりなかったのですが。
-
和泉 -
でも、必要なアラートと不要なアラートを区別できるんですか？
-
福原 -
意外と考え方はシンプルなんですよ。大きく分けると2つあり、1つ目は「不要なアラートは捨てる」、2つ目は「同じものはまとめる」です。
大量のアラートが同時に出ても、実は同じ事象を指していることも多いんですよ（汗）。
-
和泉 -
確かにそう聞くと簡単そうに思えますね！
フィルタリングのこうしたロジックは元々あったのですか？
-
福原 -
あまりなかったので、自社で作りました。こういったところで年間約1,000万件のアラートに対応してきたノウハウが活かせました。
人がやるべきことはごくわずか
-
和泉 -
過去に苦しんだ部分がサービスとして活かされている、ということですね。
-
福原 -
あとはフィルタリングで必要なアラートに絞った上で、その対応も考えなければならないですね。
-
和泉 -
対応というと障害対応などでしょうか？
-
福原 -
主な対応としては、障害発生の連絡やシステム/サービスの再起動などです。障害連絡はメールか電話で行うケースが一般的ですが、人が対応していることが、いまだに多いんです。
メールの場合は宛先や文面の確認に相当な時間がかかりますし、電話だと連絡先リストの確認や、連絡先順番の確認で思わぬ時間がかかってしまうことも少なくありません。
-
和泉 -
でも、早く知りたいから電話をお願いしてるんですよね。
-
福原 -
まさにそうなんですよ！早く障害に気付きたいのに連絡が遅れてしまう、という本末転倒な状況が起こってしまうんです。
そこでUOMではあらかじめ設定したアラートをトリガーに、自動で電話やメールする仕組みを実装しています。今となっては一般的ですね。私は、「目覚まし」機能と呼んでいます （笑）。
-
和泉 -
障害対応の方はどうですか？
-
福原 -
これも自動電話と同じような考え方で、あらかじめ設定した条件に合致した場合は「システム再起動」や「プロセス再起動」などを自動で実行する仕組みを実装しました。 この機能を「自動オペレーション」と呼んでいます。実際のところ、再起動で済むケースも多いので、この機能を利用することで復旧も自動化することができます。
-
和泉 -
アラートを受け取って、通知して、復旧する。このプロセスが自動化できるんですね。
-
福原 -
そうですね。仮にアラートがIIJほど大量でなくても、通知～復旧が効率化できるのは非常に大きいです。実際、この機能だけをご利用いただくことも多いです。
-
和泉 -
理解できました。ちなみにそれ以外の運用業務で効率化できるポイントはありますか？
-
福原 -
障害アラートをチケットシステムで行うケースがありますが、このチケットシステムにデータを入力するのって結構な手間なんです。
そこでUOMでは、まず必要なチケットを自動起票します。その上で、先ほどの自動電話や自動オペレーションが行われたら、これらの実施結果も合わせて更新します。「タイムライン」と呼んでいるのですが、このような補助機能でチケット管理を効率化できます。
-
和泉 -
タイムラインで効率化できるのですね。
-
福原 -
実はこのタイムライン機能はお客様の利用状況を見て、機能エンハンスという形で実装しました。
-
和泉 -
クラウドサービスなので定期的に機能拡張するんですよね。
実際、機能追加の頻度はどれくらいですか？
-
福原 -
だいたい半年に1回ほど新たな機能を追加していますね。お客様の生の声を反映して、より使いやすいサービスを目指しています。
-
和泉 -
まさに進化するサービスですね！運用の課題もよく分かりました。今日はありがとうございました。運用現場の負担が減るよう、今後の進化にも期待しています！
気になることがあればお気軽に