【社内資料公開】構築担当者向け 運用チームに引き継ぐ時に気にしてほしい3つのポイント

【社内資料公開】構築担当者向け 運用チームに引き継ぐ時に気にしてほしい3つのポイント

Clock Icon2015.07.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

こんにちは植木和樹@上越妙高オフィスです。AWS上でのインフラ構築が終わり、アプリケーションがデプロイされるといよいよサービスローンチ。数日〜数週間様子をみて問題がなければ運用チームに業務を引き継ぐことが多いかと思います。

運用チームへの引き継ぎ資料を作って「あとはよろしくね」となるわけですが、その段階で「待て」がかかってしまうことがあります。(だいたい待てを言うのは私なんですが)

今回はスムーズに運用チームに業務引き継ぎができるように、私が注意しているポイントをまとめておきたいと思います。

3つのポイント

注意するポイントは3つです。

1. Input
なにをトリガーに作業が始まるのか。どんな通知がくるのか。
2. Action
何をするのか。
3. Output
作業が終わったら誰に報告するのか。

1つずつ説明していきます。

1. Input

運用チームは基本的に「イベント・ドリブン」です。なにかキッカケとなる事象があって初めて動くと考えてください。きっかけには以下のようなものがあります。

  • お客様からの問い合わせ
  • 障害通知
  • 時刻(毎日◯時、毎月最終日曜日など)

また通知内容にも注意が必要です。特に障害通知がやっかいです。運用チームは大抵日々数十通〜数百通の問い合わせメールや障害通知メールを受け取っています。その中には障害ではない、いわゆる狼少年的なアラートも含まれます。そんな中から対応が必要なメールを特定します。果たしてその通知は運用チームが確実に行動を起こせる内容になっているでしょうか?

通知内容については次の「Action」も関係します。

2. Action

文字通り「通知を受け取ったら何をするか」です。引き継ぎ時にここをちゃんと伝えていないケースが意外と多かったりします。

「障害があがったらメールで通知されるので対応をお願いします」というケースを考えてみましょう。

通知内容からサーバーを特定できるようにしよう

そのメールの文面から対象の顧客、AWSアカウント、サーバーは特定できるようになっているでしょうか?通知されるメールに「prod-web01」とだけなっていないでしょうか?送信元のプライベートIPしか記載されていないなんてことはないでしょうか?

運用チームでは数十社の運用契約と数百のAWSアカウントを扱っています。メール文面にはサーバーが特定できる情報を記載しましょう。

どういう行動をとって欲しいのか明確にしよう

監視システムから「CPUが閾値を超過しました (結果:100%/閾値:80%)」というメールが届いたとします。考えられる行動はいく通りもあります。

  • 重要障害としてお客様担当者へ電話し、構築担当者へも連絡する
  • サーバーを再起動して様子をみる
  • いつものことなので放っておく

過去経験したうれしい通知は、本文の中に「この通知を受け取ったらシステム担当者([email protected]) へメールで連絡してファイル再送を指示してください」という、次の行動が明記されているものでした。通知を見ただけで迷わずに正しい対応をすることができますね!

「いつものことなので放っておく」通知は一番悪い通知の一つです。運用チームが行動する必要のないものなら通知はあげないようにしましょう!!運用チームメンバーは新しい通知が入るといつもドキッとしているのです。メンバーの心臓をいたわってあげてください。

また考えられるパターンを数十通り列挙してExcelで引き継ぐ場合があります。これはこれで嬉しいのですが、検索性に乏しい指示リストはオペミスが発生する可能性が非常に高くなるので気をつけましょう。メールのサブジェクトやエラー番号を用いて対応パターンをフィルターできるようにしておくと喜ばれるでしょう。

ところで、あらゆる通知パターンを網羅して引き継ぐのは不可能です。そんな時はプログラムと同じように「例外処理」を設けておくと良いでしょう。典型的なものとしては「見慣れない通知は構築担当者へエスカレーション」です。例外だったものがパターン化できたら改めて運用チームへ引き継いでください。

作業チェック手順も伝えよう

その作業が問題なく終わったことを確認する手順も伝えてもらえるとうれしいです。

  • とあるURLをブラウザで開いてページが表示されることを確認する
  • df コマンドを実行しディスク使用率が80%未満になっていることを確認する
  • 作成したユーザーでtouchコマンドを実行しファイルが読み書きできることを確認する

3. Output

対応が完了したら報告が必要です。例えばサーバーを再起動したら結果を誰かに報告する必要があるかもしれません。OSにユーザーを追加したらExcelで作ったユーザー台帳の更新が必要かもしれません。

  • 報告先のお客様担当者はどなたですか?
  • どういう連絡手段で伝えますか?(電話、メール、チケット管理システム)
  • なにを報告すれば良いですか?(文面のひな形が用意されていると泣いて喜ばれると思います!)

まとめ

運用チームへ業務を渡すための3つのポイントをまとめてみました。プログラムを開発する時に気にしなければならないことに似ていることが分かっていただけたかと思います。

「データファイル渡すからDBに取り込むプログラム書いて!」という指示だけではプログラムは書けないですよね。

  • ファイルはCSVなの?JSONなの?
  • どのDBのどのテーブルに取り込めばいいの?
  • データ変換テーブルにはインデックスは貼られてる?キーはデータファイルから取得できる?
  • 不正データが入ってた場合はどう処理しておけばいい?
  • 動作テストはどう行う?
  • 取り込み結果はログに残すの?メール通知は必要?

良いプログラマーは良いオペレーション指示を伝えられると思っています。このエントリーがより良いDev&Opsに繋がれば幸いです。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.