新サービス「Pigeon」を正式リリースしました 他

Kompira cloudについて、以下の内容を含むアップデートを行いました。

新サービス「Pigeon」を正式リリースしました

エスカレーション電話連絡を実現する新サービス「Pigeon」を2019年2月からベータ版として公開しておりましたが、この度正式版としてリリースを行いました。

f:id:kompiracloud:20190523110831p:plain
Pigeon 構成イメージ

複数の連絡先を束ねてコールフローを作成し、 登録順に自動音声電話をかけるまでの一連の流れをサービスだけで完結させることができます。 チュートリアルはこちらからご覧いただけますので、ぜひご一読ください。

[Sonar] ksocketの認証情報ファイル生成機能を追加しました

ksocketからLinuxやWindows、ネットワーク機器に接続する際に必要な情報は、toml形式で記述をします。
今回のアップデートにより、Web上で項目を入力することで、対応するtomlファイルを生成できるようになりました。

f:id:kompiracloud:20190520144532p:plain
画面上の設問に答えていくだけで有効なtomlファイルを生成できます。

Kompira cloudにログイン後、画面右上の全体設定->認証情報というメニューからお使いいただくことができます。
なお、本機能はJavaScriptのみで完結しており、入力されたユーザ名、パスワード、IPアドレスなど一切の情報はKompira cloudには送信されません。
APIの提供はございませんので、ご注意ください。

[Sonar] ksocket のアップデート

以下の内容を含むアップデートを行いました。

  • ksocket-20190510

    • ksocket-core: 1.8.0
    • ksocket-networks: 1.7.0
  • アンインストールが1コマンドで行えるようになりました

  • その他、いくつかの不具合修正、安定性の向上を行いました

最新の ksocket はこちらよりダウンロードすることができます。



Kompira cloud 製品紹介ページはこちら
Kompira cloud 資料ダウンロードはこちら

Pigeon チュートリアル

はじめに

Kc Pigeonは複数人のチームに対して、誰かから応答があるまで電話連絡を順番に行うサービスです。連絡の内容は自動音声によって再生され、電話をうけた人は1~9の数字を押すことで応答内容を決めることができます。

ここでは、Kc Pigeon における連絡内容の設定と、連絡の実行をAPI経由で行う方法をご紹介します。

連絡内容の設定

連絡内容の設定は、Kompira cloud Web画面右側の「Pigeon」メニューより行うことができます。

f:id:kompiracloud:20190517140331p:plain

連絡先とコールフローの作成

まずは、電話での連絡先情報を作成しましょう。 今回は、田中さん、山田さん、斎藤さんの3人に対して順番に電話がかかるようにデータを作成してみます。Kc Pigeonでは、このように複数人が連なった一連の連絡先を「コールフロー」と呼びます。

連絡先の作成

まず、田中さん、山田さん、斉藤さんの名前と電話番号情報をそれぞれ作成します。
以下は田中さんの電話番号情報を登録している様子です。

f:id:kompiracloud:20190517141443p:plain
名前と電話番号の登録

同じように山田さん、斎藤さんの情報を登録すると、連絡先一覧表示画面では以下のような状態となります。

f:id:kompiracloud:20190517141610p:plain

続いて、田中さん、山田さん、斉藤さんが登録されたコールフローを作成しましょう。

コールフローの作成

f:id:kompiracloud:20190517144909p:plain

「連絡順」にて、先ほど追加した連絡先を元にどういった順番で電話連絡をするかを決めることができます。
また、誰も応答しない場合には連絡の再試行を行いますが、最終的に連絡を何回まで行うかは「最大ループ回数」にて設定します。
(例えば「1」の場合は再試行を行わず、1回で連絡を終了します)

今回の例では、以下の順序で電話がかかることになります。

電話開始 -----+-----> 田中さん ---> 山田さん ---> 斉藤さん -->+-------------> 電話終了
             ↑                                             |
             |                                             |
             |                                             ↓  (3周していなければ戻る)
             +---------------------------------------------+

ガイダンス情報の作成

連絡前の最後の準備として、電話を受けた際に自動音声で流れる文章を作成しましょう。Kc Pigeonではこれを「ガイダンス」と呼びます。

ガイダンスの登録をする場合、「電話を受信したらはじめに流れる音声の文章」と、その後「1~9を押した時に流れる音声の文章」をそれぞれ登録します。
まず、ガイダンス情報の登録画面を見てみましょう。

f:id:kompiracloud:20190517150408p:plain

ガイダンスでは、自動音声の他に、番号の押したときの振る舞いを指定することができます。 この番号および振る舞いは、マウスクリックすることで切り替えることができます。

振る舞いには以下の3種類があります。
(最低でも1つは「終了」の動作が割り当てられた番号を設定する必要があります。)

動作 意味
終了 一連の連絡を終了させます。次の連絡先への電話連絡は行われません。
継続 コールフローの次の連絡先へ電話連絡を行います。
離脱 コールフローの次の連絡先へ電話連絡を行います。
また、次回以降のループで自分への電話連絡が行われないようになります。

電話に出なかったり、番号を押さずに電話を切った場合は「継続」と同様、次の連絡先へ電話連絡を行います。

試しに、あるサーバに障害が発生したとき、それを運用担当者に知らせるようなガイダンスを作成してみましょう。

タイミング 動作 メッセージ
電話受信時 {{server}}にて{{incident}}が発生しました。
対応される場合は1を、次の担当者に連絡する場合は2を、
次回以降この電話への連絡をスキップする場合は3を押してください。
1が選択された時 終了 1が押されました。対応をよろしくお願いいたします。
2が選択された時 継続 2が押されました。次の担当者に連絡します。
3が選択された時 離脱 3が押されました。次回以降、この電話への連絡をスキップします。

この内容で障害連絡を受けた担当者は、1を押すことで自分が対応を行う(以降の連絡が不要である)ことをPigeonに知らせ、連絡を止めることができます。 また、何らかの事情で対応が難しい場合は、2または3を押すことで次の担当者に回すことができます。

なお、「電話受信時」のメッセージに含まれる {{server}} {{incident}} といったキーワードは、連絡を実施する際に具体的な単語に置き換えて連絡をすることが出来ます。 具体的な使い方に関しては後述する「コールフローを用いて連絡をする」の内容をご覧ください。

連絡の実行

それでは、ここまでに入力したデータを使って連絡を行ってみます。連絡はAPI経由で実行することになります。

※ 本ステップを実行するためにはPigeonの利用契約が必要となります。ご利用希望の場合はお問い合わせフォームよりその旨ご連絡ください。
Kompira cloud お問い合わせフォーム
https://www.fixpoint.co.jp/cloudcontact/

APIトークンの作成

Kompira cloudのAPIを使用するために、まずはAPIトークンの発行を行いましょう。

発行を行うにはブラウザからKompira cloudにアクセスし、画面右上の 全体設定 > APIトークン を開きます。

f:id:kompiracloud:20190206150550p:plain:w600

f:id:kompiracloud:20190206150639p:plain:w600

作成されたAPIトークン文字列を保存しておきます。

コールフローを用いて連絡をする

Pigeonでは「コールフロー」に登録された連絡先に対して、登録された順番で電話連絡を行います。 また、読み上げ文面には「ガイダンス」に登録された内容を用います。 そのため、連絡をするには「コールフロー」「ガイダンス」を1つずつ指定します。

それでは実際に自動音声による連絡を行なってみましょう。

連絡の実施 : [POST] /api/tasks

POST時のJSONデータは以下のような形式で指定をします。

{
  "namespace": "pigeon",
  "method": "chain",
  "params": {
    "callflowId": "bf72caa6-34fa-4032-aaa1-cf6136c9a9a5",
    "guidanceId": "60125ed2-4f8a-485d-8c60-d885ad76f37a",
    "parameters": {
      "server": "テスト用サーバー",
      "incident": "軽度の障害"
    }
  }
}

params.parameters に指定された値は、ガイダンスで {{key}} という形式で書かれた部分に埋め込まれます。 例えば「{{server}}{{incident}}が発生しました」というメッセージをガイダンスに登録した場合、上記のJSONデータで連絡を実行すると「テスト用サーバー軽度の障害が発生しました」という内容が実際に読み上げられます。

以下はcurlコマンドを使ったAPI実行の例です。

$ curl -X POST -H "X-Authorization: Token aAbBcCdDeEfFgGhHiIjJkKlLmMnNoO0123456789" \
https://yourspace.cloud.kompira.jp/api/tasks \
-d '{"namespace":"pigeon","method":"chain","params":{"callflowId":"bf72caa6-34fa-4032-aaa1-cf6136c9a9a5","guidanceId":"60125ed2-4f8a-485d-8c60-d885ad76f37a","parameters":{"server":"テスト用サーバー","incident":"軽度の障害"}}}'

ここで、 aAbBcCdDeEfFgGhHiIjJkKlLmMnNoO0123456789 となっている部分は、前の項で発行したAPIトークンを設定してください。 また、 https://yourspace.cloud.kompira.jp の部分は実際にお使いいただいているKompira cloudのスペースURLを設定してください。

APIを実行すると、以下の順で処理が進みます。

  • 田中さんに電話連絡
  • 山田さんに電話連絡
  • 斎藤さんに電話連絡
  • (田中さんに戻る)

この中で、誰かが「1」を押した時点で連絡は終了となり、以降の電話連絡は行われません。
「2」が押される、番号を押さずに電話が切られる、電話に出ない、等の場合は次の人への電話連絡を行います。

まとめ

簡単ではありますが、Kc Pigeonによる連絡の方法をご紹介しました。

なお、連絡の実施だけでなく、連絡先・コールフロー・ガイダンスの登録・取得を含む全ての操作はWebAPIからも実施可能です。 API一覧は、APIドキュメントPigeon カテゴリから確認することができますので、詳しくはそちらをご参照ください。

Windows版ksocketを公開しました

Kompira cloudでは構成情報の自動収集(スキャン)を行うために、ksocketというモジュールを使用します。

ksocketはこれまでLinuxをサポート対象としておりましたが、今回のアップデートによりWindowsをサポート対象として追加し、インストールパッケージを公開しました。

以下のOSを対象としています。

  • Windows Server 2012
  • Windows Server 2012 R2
  • Windows Server 2016

最新の ksocket はこちらよりダウンロードすることができます。
ksocketを新規インストールするときはksocketドキュメントの2.1章を参考にインストールを行ってください。
ksocketをアップデートするときは、ksocketドキュメントの2.2章に記載されたアンインストールを行ったのち、2.1章のインストールを行ってください。

Kompira cloud 製品紹介ページはこちら
Kompira cloud 資料ダウンロードはこちら

API経由でスキャンのスケジューリング設定ができるようになりました 他

Kompira cloudについて、以下の内容を含むアップデートを行いました。

API経由でスキャンのスケジューリング設定ができるようになりました

スキャンの定期的な実行、スケジューリングの設定を行うことができるようになりました。

日に1回、週に1回、月に1回のスキャン実行を指定することができます。

メール通知設定と組み合わせることで、「毎週自動で環境をスキャンし、新しいノードが見つかったり、スキャンが異常終了したときにメールが送信されるようにする」といった設定ができます。

詳細は、 APIドキュメント の以下のエンドポイントを参照して下さい。

  • [GET] /api/tasks/schedules
  • [POST] /api/tasks/schedules
  • [GET] /api/tasks/schedules/{taskScheduleId}
  • [PUT] /api/tasks/schedules/{taskScheduleId}
  • [DELETE] /api/tasks/schedules/{taskScheduleId}
  • [POST] /api/tasks/schedules/verify

API経由でスキャン状況にあわせてWebhook通知設定ができるようになりました

以前、スキャン状況にあわせてメールを送信できる機能をリリースいたしましたが、メールに加えてWebhookでの通知機能を追加しました。 メール送信の設定の時と同様、以下のタイミングでWebhookを送信することができます。

  • スキャンが開始した時
  • スキャンが正常終了した時
  • スキャンが異常終了した時
  • 新しいノードが発見された時
  • 30日以上未検出のノードが発見された時

詳細は、 APIドキュメント の以下のエンドポイントを参照して下さい。

  • [POST] /api/apps/sonar/networks/{networkId}/notification-settings
    • emails の代わりに webhook.url を指定することで、そのURLに対してデータをPOSTします。

ksocket のアップデート

以下の内容を含むアップデートを行いました。

  • ksocketバージョン
    • ksocket: 1.6.5
    • ksoperations-networks: 1.6.4
  • 複数の IP アドレスが紐付いたインターフェースを持つホストでスキャンすると、スキャンがキャンセルされる問題を修正しました。

最新の ksocket はこちらよりダウンロードすることができます。



Kompira cloud 製品紹介ページはこちら
Kompira cloud 資料ダウンロードはこちら

「ssmjp ヤマサキ春のサメまつり」に参加してきました

こんにちは、三角です。

3月6日に開催された「ssmjp ヤマサキ春のサメまつり」に参加してきました。

ssmjp.connpass.com

ssmjpについて

今回は、波田野さんが「運用自動化」とは何か"を再整理して「ssmjp ヤマサキ春のサメまつり」で発表するよという事だったので、始めてssmjpに参加してきました。

ちなみに、ssmとは新橋・スタディー・ミーティングの略で、 コンセプトは「アウトプットしないのは知的な便秘」でLTの練習場的な位置づけな勉強会だそうです。

基本はインフラ運用系の勉強会だけれども、面白ければ何でもいい。スペシャルコラボの会もある。 どんなネタを話してもOKで、キャンギャルの話とか出会い系の話も過去にあったそうです。

ちなみに今回は、ssmjpとJAWS-UGとのコラボ企画で、 サメまつりという事なので、JAWS-UGの話が中心なのかと思ってました。

登壇感想等

「サメの話」まさしさん

サメは、2016年3月末時点で世界中に509種が確認されており、日本では130種生息 サメの事故 2018年 130件。サメの死亡事故 年間5人死亡。 と、まじめにサメの話が始まり、JAWS-UGのかけらもありませんでした。

近年のサメの進化がすごいという事で、サメの映画の説明まで、、 MEGザ・モンスター、メガ・シャーク、ダブルヘッドジョーズ、トリプルヘッドジョーズ、ファイブヘッドジョーズ、シックスヘッドジョーズ、、、、 そんなにサメの映画があるんですね。 勉強になりました。。

「愛知県豊根村でチョウザメの養殖場見学とチョウザメを食してきた話」吉江さん

ここでもJAWS-UGではなく、サメの話。(チョウザメはサメではないけどと断り付きの発表でした) 日本にチョウザメの養殖をしているところがあるのは初めて知りました。

チョウザメのコース料理を食べられる宿で食べてこられたそうですが、 フグやタイのようなおいしい魚だったそうです。

「運用自動化とは」波田野さん

2018年は、運用自動化への過剰な期待を冷却する活動を行ってきたハタノさん、自動化否定派と言われる事もあるそうです。 といいつつ、ダメな運用自動化の3類型をぶち込んでくるあたり、さすがハタノさん!

今回の運用自動化のポイントは下記の3点と捉えました。

  1. 運用はサービスを継続的にデリバリする事であり、事業継続性の実現である

  2. 運用自動化の本質は事業継続性の向上であり、手順書なき自動化は事業継続性の低下につながる

  3. 運用自動化がサービス価値、デリバリ価値向上につながるか検討する必要がある

システム運用の業務に携わっていると、目の前の事に追われ、運用とは何なのかを考える機会があまりないので、ポイント1は非常にいい視点だなと思っています。また、この自動化がどういう価値を生むのかをあまり検討することなく、自動化やツール導入などの手段が目的になっているケースもままありますので、参考になる運用現場が多いのではないでしょうか。最近、運用は人気が無く、若手を配属してのすぐに辞めちゃうという話も聞きます。向かうべきところがわからず、ただ単に目の前の業務を維持する為に、手順通り対応しろ、24時間365日対応しろと言われるのであれば、モチベーションが上がらないのもよくわかります。それぞれの運用現場にとって、俺たちの価値とは何で、価値を具体的な数値として目標を設定し、効果測定し、継続的に改善していく事が出来ていければ、やりがいのある運用現場になるのではないかと思います。

ポイントの2に関しては、おおむね賛成なのですが、手順書の部分は、自動化の仕様書にした方が勘違いが無くていいかなと思いました。 よくある手順書は、人が運用する為の手順が書かれているもので、自動化には不向きな手順も多数あります。また、人がやる運用であれば、何か課題があったら誰々さんに連絡ですむ話も、自動化なら、異常系の処理を設計に盛り込んでいく必要があります。そのあたりは開発者としての視点が求められますので、手順書より仕様書の方が、個人的にはすっきりするかなと。

ダメな運用自動化の3類型は、自動化やっていると、うん、あるあるという内容。これが、はてブのホッテントリ入りしたようなので、世の中の自動化リテラシーは随分と上がってきたんだなと感心しました。やったことないと響かないですし。

2011年の運用ドキュメントモデルから運用のあるべき姿を追求してきたハタノさんだからこそ、まとめ上げられた渾身のスライドは公開されていますので、下記のURLをご覧ください。

speakerdeck.com

speakerdeck.com

SNMPv3によるスキャンに対応しました 他

ksocket について、以下の内容を含むアップデートを行いました。

  • ksocket: 1.6.5
  • ksoperations-networks: 1.6.2

SNMPv3によるスキャンができるようになりました

SNMPで構成情報を取得する際、これまではSNMPv2cでのスキャンに対応していましたが、今回のアップデートでSNMPv3でもスキャンが行えるようになりました。

以下はSNMPv3での接続設定ファイルの設定例です。

$ cd /opt/fixpoint/ksocket/etc/ksocket/credentials/snmp
$ cp 999-example.toml.skeleton 200-v3test.toml
$ vi 200-v3test.toml

includes = ["10.10.0.0/24"]

port: 161

[authData]
# ユーザ名
username = "your-username"

# 認証方式
# - usmNoAuthProtocol (認証なし、default)
# - usmHMACMD5AuthProtocol (MD5(HMAC-MD5-96) に対応)
# - usmHMACSHAAuthProtocol (SHA(HMAC-SHA-96) に対応)
# - usmHMAC128SHA224AuthProtocol
# - usmHMAC192SHA256AuthProtocol
# - usmHMAC256SHA384AuthProtocol
# - usmHMAC384SHA512AuthProtocol
authProtocol = "usmHMACMD5AuthProtocol"

# 認証パスワード
#authKey = "your-password"

# 暗号化方式
# - usmNoPrivProtocol (暗号化なし、default)
# - usmDESPrivProtocol (DES(CBC-DES))
# - usm3DESEDEPrivProtocol (3DES-EDE)
# - usmAesCfb128Protocol (AES(CFB128-AES-128))
# - usmAesCfb192Protocol (AES(CFB128-AES-192))
# - usmAesCfb256Protocol (AES(CFB128-AES-256))
privProtocol = "usmAesCfb128Protocol"

# 暗号化パスワード
privKey = "priv-your-password"

設定ファイルの標準形式を変更しました

ksocketの設定ファイル、credentialファイルの標準形式はこれまでYAMLを採用していましたが、今回のアップデートよりTOML形式での記述に対応しました。

以下は、同じ内容の設定ファイルで、左が従来のYAML形式、右が今回対応したTOML形式での記述例です。

f:id:kompiracloud:20190313162129p:plain
左: YAMLファイル, 右: TOMLファイル

TOML形式では、文字列の指定のときに username = "john" のようにクォートで囲む必要があることに注意してください。

YAMLファイルとTOMLファイル両方がある場合、TOMLファイルが優先されるようになります。ksocketアップデートを行う場合はご注意ください。
また、今後はTOMLファイル形式を標準とし、YAMLファイル形式のサポートは将来的に廃止予定 (deprecated) となります。

最新の ksocket はこちらよりダウンロードすることができます。
ksocketを新規インストールするときはksocketドキュメントの2.1章を参考にインストールを行ってください。
ksocketをアップデートするときは、ksocketドキュメントの2.2章に記載されたアンインストールを行ったのち、2.1章のインストールを行ってください。

Kompira cloud 製品紹介ページはこちら
Kompira cloud 資料ダウンロードはこちら

コンピュータからインターフェース一覧情報を取得する機能を追加しました

Kompira cloudについて、以下の内容を含むアップデートを行いました。

コンピュータからインターフェース一覧情報を取得する機能を追加しました

これまでKc Sonarでは、スキャン時にアクセスしたアドレスの一覧情報を表示していました。
今回のアップデートではこれに加えて、LinuxおよびWindowsにおいて、その機器の中のネットワーク・インターフェース一覧を取得できるようになりました。

機器中のインターフェース一覧より、IPv4アドレスの一覧とそれに対応した以下の情報を取得し、表示します。

  • インターフェース名
  • ネットマスク
  • MACアドレス
  • MACアドレスに対応したベンダー名

この変更は、本日以降スキャンしたスナップショットおよびノードに適用されます。


例えば以下はUbuntu 16.04サーバをスキャンさせた例です。
ksocketからアクセスしたのは 10.20.11.91 ですが、Ubuntuサーバが持っているその他のインターフェース情報も取得できていることがわかります。

f:id:kompiracloud:20190219192049p:plain
Ubuntuでのスキャン例

Windowsの場合も以下のように取得することができます。

f:id:kompiracloud:20190219192831p:plain
Windows 10でのスキャン例