資産管理とリース契約の管理について

こんにちは、三角です。

PC資産やリース契約等の情報をExcelで管理されている方も多いと思います。

知らないPC資産があり管理から漏れていた、リース契約の期日の確認が漏れており更新に影響が出たなど、Excelを利用した人力での管理には限界を感じる事はありませんか?

Kc SonarではITサービスマネージメントツールと連携する事で、定期的なスキャンによりPC資産の確認し常に最新状態を保ち、その資産情報とリース契約を紐づけて管理する事により期日の一か月前に通知する等を自動行えるようになりますので、管理漏れが無くなります。

連携できるITサービスマネージメントツールは、ServiceNow、LMIS on cloudなどAPIが利用できるものであれば、なんでも問題ありません。

是非、ご検討ください!

新サービス「Pigeon」のベータ版を公開しました

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

新サービス「Pigeon」のベータ版を公開しました

エスカレーション電話連絡を実現する新サービス「Pigeon」のベータ版を公開いたしました。

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

ベータ版はAPIのみのご提供となりますが、複数の連絡先を束ねてコールフローを作成し、
登録順に自動音声電話をかけるまでの一連の流れを検証いただくことが可能です。

ご興味がございましたら、下記のフォームよりお問い合わせください。

Kompira cloud お問い合わせフォーム
https://www.fixpoint.co.jp/cloudcontact/

メンテナンス後の監視再開忘れ

こんにちは、三角です。

2/2にクレジットカードの決済システムの障害のニュースがありました。

知人からはSUICAをクレジットカードチャージにしていて、チャージが出来ず駅に入れなかったため、 久しぶりに切符を買おうとしたら、買い方を忘れてしまってまごついたなんて話も聞きました。

決済システムは社会インフラなので、障害が起きると影響が大きいですね。

今回は障害にすぐに気が付いたので良かったですが、 メンテナンスの時に止めた監視を、メンテナンス終了後監視再開する事を忘れたことはありませんか?

監視再開を忘れていて、監視対象のシステムに障害が発生したら、まったく検知する事が出来ませんので、 対応の初動も遅れ、被害も拡大してしまう為、想像しただけで冷や汗が出ますね。

定期的にちゃんと監視をしているのか目視で確認するという方法もありますが、それも大変なので、自動でやらせたい!

そこで、「Kompira cloud Sonar」の出番です。

あなたのお使いの監視ツールは、Zabbixですか? それともNagios、hinemosなどのOSSですか? JP1、SystemWalker、Senju、SystemAnswer、パトロールクラリス等の商用ツールですか? それとも、Macarel等のクラウドサービスですか?

どの監視ツールをお使いでも、Kompira cloud Sonarで監視対象システムの構成情報を自動で管理しておけば、 監視ツールと連携して、対象を監視しているか自動で確認する事ができます。

Zabbixとの連携事例は、こちらの記事をご覧ください。

blog.cloud.kompira.jp

スキャン状況にあわせてメール通知を行える機能を追加しました 他

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

スキャン状況にあわせてメール通知を行える機能を追加しました

以下のタイミングでメールを送信するように設定することができるようになりました。

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

f:id:kompiracloud:20190111183920p:plain


「メール通知設定の追加」をクリックすると、送信先のメールアドレスと、送信するタイミングを設定することができます。

上記で保存した状態でスキャンを実行すると、以下のようなメールが送信されます。

  • スキャンが開始した時のメール内容
title: [demospace/社内ネットワーク] スキャンを開始しました

ネットワーク 社内ネットワーク を対象としたスキャンを開始しました。

この結果は以下のURLで確認することができます。

https://demospace.cloud.kompira.jp/apps/sonar/networks/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/snapshots/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

※このメールは自動で送信されています。返信はできませんのでご注意ください。
※このメールにお心当たりのない方は、恐れ入りますが破棄して頂けますようお願いいたします。

------------------------------------------------------
Kompira cloudサポート
お問い合わせ  https://www.fixpoint.co.jp/cloudcontact/
------------------------------------------------------
  • 新しいノードが発見された時のメール内容

    以下の例では、スキャンによって新しく3台のノードが発見されています。

title: [demospace/社内ネットワーク] 新規ノードを発見しました

ネットワーク 社内ネットワーク を対象としたスキャンによって、以下のノードが新規に発見されました。

https://demospace.cloud.stg.kompira.jp/apps/sonar/networks/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/managed-nodes/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
https://demospace.cloud.stg.kompira.jp/apps/sonar/networks/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/managed-nodes/yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy
https://demospace.cloud.stg.kompira.jp/apps/sonar/networks/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/managed-nodes/zzzzzzzz-zzzz-zzzz-zzzz-zzzzzzzzzzzz

※このメールは自動で送信されています。返信はできませんのでご注意ください。
※このメールにお心当たりのない方は、恐れ入りますが破棄して頂けますようお願いいたします。

------------------------------------------------------
Kompira cloudサポート
お問い合わせ  https://www.fixpoint.co.jp/cloudcontact/
------------------------------------------------------

その他の改善と修正

  • APIドキュメントページからswagger.ymlファイルをダウンロードできるようにしました
  • 大規模なネットワークをスキャンしたときにスキャンが正しく完了しない問題を改善しました

運用現場に必要なのは、始める事より「やめる」こと

こんにちは、三角です。

最近、色々な運用の現場の方から、若いエンジニアを配属してもなかなか定着しない。すぐに辞めていってしまうという話を聞きます。

ただでさえ人手不足で採用が思うようにいかない状況の中、若手が定着しないのはなぜでしょうか?

その理由は、「裁量」の不足です。

様々なサービスが24時間昼夜問わず提供されており、それをシステムが支えている。昼間しか稼働してない企業でも、夜間しかできない処理が走っている。システムは24時間止められません。

システムに何か起こったら仕事が滞るため、すぐに対処できるように監視センターは24時間稼働していて、シフト交代で詰めている人たちがいます。夜勤もあり、正月もGWもお盆も、みんなが休んでる時に働かなくてはなりません。

監視センターから緊急のエスカレーションを受ける人がいます。常に携帯を離さず、寝ている時も電話があると、すぐに起きて対応しなければならない。隣で小さな赤ちゃんが寝ていても、年老いた両親が寝ていても、電話に対応しなければいけません。

働き方改革で働きやすさを追及していこうという世の中の流れの中で、このような環境で働くというのはとても働きにくさを感じると思います。

しかし、人は働きやすさだけを考えて働いているわけではなく、働き甲斐も非常に大事な要素です。

「内発的動機付け」の研究で有名な心理学者のエドワード・L. デシによると、人は、誰かから(外発)与えられた報酬(金銭、地位、名誉など)よりも、達成感、有能感など自分自身の心、つまり内から発せられるもの(内発)によってこそ、よりモチベーションを高め自ら行動を起こしていくとの事で、この内発性の高める環境条件のひとつとして「選択の自由」があり、そして「自己決定」があります。

システム運用の現場に、選択の自由と自己決定ができる環境はどのくらいあるでしょうか。

運用業務の効率化をしたいという話を聞くと、まず今やっている業務をリストアップし、整理すべきだと話しますと、みんな賛成します。

しかし、大変な割に効果がイマイチなものをピックアップし、これはやめたらどうかと話をすると、いやいや、それは無理だ、それは変えられないなどど返答が返ってくるわけです。

今までは、運用はコストセンターだから予算を消化するだけで、今までのやり方を踏襲しておけばよい。新しい事は出来ないといっておけばよい。という風潮の中で業務を維持し続けてきた先輩方からしてみると、これは変えられない、これをやめるのは無理だとなりますが、若手からしてみると、「選択の自由」や「自己決定」の裁量は与えられないと感じるのも無理はないことかと思います。

SPAMメールの対策ツールを入れたものの、誤って正しいメールを隔離してしまうバグがあり、誤隔離されたメールを手動で戻す運用を行っている。

メモリーリークするアプリケーションを運用しており、毎週1回何時にリブートする事という手順を何年も守っている。

このような運用を続けて意味がありますか?

実務を知らない上の意思決定が現場の若手をすり減らしてませんか?

まずは、そのような運用を見直し、やる理由のないものはやめていく。

運用現場にそのような裁量がまさに求められているのではないでしょうか?

そして、自分たちで選択し、決定できるようになった若手は、より効率化を行う為に、自ら自動化をすすめ、品質向上やコスト削減、要員対策につながっていきます。

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

サービスを導入する時に上司を説得する方法

UI/UX担当の福原です。

UXとは、「製品、システム又はサービスの使用及び/又は使用を想定したことにより生じる個人の知覚と反応」 であると、ISOで定義されている件については以前の記事でご紹介させて頂きました。

仕事として必要な製品を導入するとなると、この流れがもう少し複雑になると思います。企業の中で仕事をする以上は、自分が必要だと思うものを自由に購入したり使用したりできませんよね。要望があれば、上司に確認してOKをもらわないといけません。

そう、あれです。

「稟議」です。

会社なのだから当然と言えば当然なのですが、非常に面倒くさい作業です。

どれだけ念入りに準備しても、

持って行き方を間違えると玉砕します

f:id:fukuharax:20181122160910p:plain

そして、これは皆さん共感して頂けると思うのですが、一度玉砕した提案の再挑戦は何倍もハードルが上がりませんか。

一回目の提案がいかに大事か、ということですね。

Kompira cloudを気に入ってくれたユーザーさんが上司に提案する時点で玉砕したり、何度もチャレンジして最終的に心が折れてしまったりしないよう、UXデザイナーとしてお手伝いできることはないかと考えました。

「上司の心に響く内容」って何だと思いますか?

たくさんの企業様にヒアリングさせて頂いたり、アンケートの結果を考えるに、

1. コスト削減

2. 品質向上

3. 売上拡大

この3つが核ではないかと思います。

なーんだ、そんなこと?

と言われそうですが、稟議を上げる際にこれをちゃんと盛り込めていないケースが結構多い気がします。 ついつい機能の話に終始してしまったり、効果を示せていなかったり。実は自分の経験でも、サービスの説明の際に機能の話から始めると失敗しがちです。

「それで、結局なんなの?そのサービス入れたらどんな効果があるの?」

上司からこの質問が出てしまったら、玉砕は目前です。 もちろんここで効果を説明できれば良いのですが、このタイミングで説明できるくらいならとっくにしているはず。 そう、この質問が出た時には、効果の説明ができないことが確定してしまっている時なんです。

ということで、今回少しでも稟議の手間を省ければと思い、社内検討向け資料をサイトからダウンロードできるようにしました。

Kompira cloud 資料ダウンロード

f:id:fukuharax:20181122161714p:plain

こんな内容も盛り込んで欲しいよ!という意見など頂けたら幸いです。

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

プロキシ経由でksocketを使用する

ksocket を使用するためには、 ksocketとKompira cloudの間でwebsocket通信を確立する必要があります。
ここでは、インターネットに接続するためにプロキシサーバを経由するような環境下で ksocket を実行するための方法を解説します。

ksbridge について

ksbridge は、プロキシサーバを経由する環境下で ksocketとKompira cloud間の通信を行えるようにするミドルウェアです。
以下の図のように、ksocketとKompira cloudの間のブリッジとして動作します。
この図では ksocketとksbridge間の通信に8080ポート、ksbridgeとプロキシサーバ間の通信に3128ポートを例として記載していますが、設定により変更可能です。

+---------------------------------------------+
| intranet                                    |
|                                             |
| +--------------------------------+          |
| | localhost                      |          |
| | +---------+      +----------+  |      +-------+     +---------------+
| | | ksocket | 8080 | ksbridge |  | 3128 | proxy | 443 | Kompira cloud |
| | |         |<---->|          |<-=------=-------=---->|               |
| | |         |  IN  |          |  | OUT  |       |     |               |
| | |         |      |          |  |      |       |     |               |
| | |         |      |          |  |      |       |     |               |
| | +---------+      +----------+  |      +-------+     +---------------+
| +--------------------------------+          |
|                                             |
+---------------------------------------------+

ksbridge を使用する場合、こちらのページ からダウンロードしてください。

使用方法

ksbridge の起動

ksocket をインストールしたサーバに ダウンロードしたksbridgeのファイルを配置し、展開してください。

$ tar zxf ksbridge_0.2.0_linux_x86_64.tar.gz
$ cd ksbridge_0.2.0_linux_x86_64
$ ls
ksbridge  README.md

ファイルが展開できたら、ksbridgeを起動してみましょう。
起動の前に、使用しているプロキシサーバのアカウント情報とポート番号を確認してください。

ここでは、以下のような環境であると仮定して、対応したksbridgeの起動コマンドを記載します。

項目
Kompira cloudのスペースURL yourspace.cloud.kompira.jp
プロキシサーバURL your.proxyserver.co.jp
プロキシサーバのポート番号 3128
プロキシサーバのアカウント名 username
プロキシサーバのアカウントパスワード password
ksocketとksbridge間の接続に使用するポート 8080
$ ./ksbridge -bind 127.0.0.1:8080 -host yourspace.cloud.kompira.jp -proxy http://username:password@your.proxyserver.co.jp:3128
********************************************************************************
ksbridge - Tiny websocket connection bridge server

  listen: ws://127.0.0.1:8080/api/ksocket/connect
  server: wss://yourspace.cloud.kompira.jp/api/ksocket/connect
  proxy:  http://username:password@your.proxyserver.co.jp:3128

********************************************************************************

プロキシサーバへのアクセスにアカウントが必要ない場合は、以下のように指定します。

$ ./ksbridge -bind 127.0.0.1:8080 -host yourspace.cloud.kompira.jp -proxy http://your.proxyserver.co.jp:3128

実行すると、ksbridgeはksocketからの通信を待つ状態となります。

ksocket の設定

次に、ksocketの設定を行います。 まずは、 ksocketドキュメント を参照し、ksocketのインストールを行いましょう。
通常 ksocket の設定ファイルには Kompira cloudのスペースURLを指定するのですが、 ksbridgeを使用する場合、スペースURLは前述のとおり ksbridge 側に設定することになります。
ksocket の設定ファイルには、代わりに ksbridge に対して接続する情報を設定します。

ksocket の設定ファイルである、ksocket.yml を以下のように編集してください。

connect:
  host: '127.0.0.1'   
  port: 8080             # ksbridge の bindポートに変更する
  protocol: ws          # wss から ws に変更する。設定行が存在しない場合は追加する
  token: FrKc+82kZGG9sdRS5AXnemPN8u6sDdY3PXxbqdB4    # Kompira cloud上で発行したksocketトークンを設定する

(以下省略)

ksocket の起動

ksocket.yml の設定を反映するために、 ksocket サービスの再起動を行います。

$ systemctl restart ksocket

再起動をすると、ksocketは設定に従って自分の8080ポートにアクセスをしにいきます。 正常に接続ができた場合、ksbridgeでは以下のような表示となります。

$ ./ksbridge -bind 127.0.0.1:8080 -host yourspace.cloud.kompira.jp -proxy http://username:password@your.proxyserver.co.jp:3128
********************************************************************************
ksbridge - Tiny websocket connection bridge server

  listen: ws://127.0.0.1:8080/api/ksocket/connect
  server: wss://yourspace.cloud.kompira.jp/api/ksocket/connect
  proxy:  http://username:password@your.proxyserver.co.jp:3128

********************************************************************************
INFO[0011] connecting to client...
INFO[0011] client has connected
INFO[0011] connecting to server...
INFO[0011] server has connected

また、Kompira cloud にアクセスし「全体設定 > ksocket」を表示後、対象の ksocket を選択してください。 接続状況が「接続済」となっていれば ksocket は正常に Kompira cloud に接続できています。

f:id:kompiracloud:20181212193113p:plain

これで ksbridge を介した ksocket と Kompira cloudの接続は完了です。



トラブルシューティング

ksbridge に何も出力されない

ksocketの設定を行い再起動を行っても ksbridge にログが表示されない場合、ksocketがksbridgeに接続しにいけていない可能性があります。
このような場合は、 ksocket のログファイル (デフォルトであれば /opt/fixpoint/ksocket/var/log/ksocket/ksocket.log ) を確認してみましょう。

2018-12-12T19:40:13+0900  DEBUG  ksocket.channel.session:_connector:241  Resumer is waiting disconnection...
2018-12-12T19:40:13+0900  DEBUG  ksocket.channel.session:_connector:243  Disconnected from the peer. Resume connection...
2018-12-12T19:40:13+0900  DEBUG  ksocket.channel.session:_resume:213  Connecting to the peer. Wait 60.000000 seconds...
2018-12-12T19:40:13+0900  WARNING  ksocket.channel.session:_resume:225  Failed to start/resume session: [Errno 111] Connect call failed ('127.0.0.1', 8080). Wait 0 sec... [1/120]
2018-12-12T19:40:13+0900  DEBUG  ksocket.channel.session:_resume:213  Connecting to the peer. Wait 60.000000 seconds...
2018-12-12T19:40:13+0900  WARNING  ksocket.channel.session:_resume:225  Failed to start/resume session: [Errno 111] Connect call failed ('127.0.0.1', 8080). Wait 0 sec... [2/120]
2018-12-12T19:40:13+0900  DEBUG  ksocket.channel.session:_resume:213  Connecting to the peer. Wait 60.000000 seconds...
2018-12-12T19:40:13+0900  WARNING  ksocket.channel.session:_resume:225  Failed to start/resume session: [Errno 111] Connect call failed ('127.0.0.1', 8080). Wait 0 sec... [3/120]

例えば上記のようなログがksocket.logに出力され続けている場合、ksbridge に接続できていない状態です。ksocket.yml での設定を再度確認してみてください。

また、別のパターンとして以下のようなログが出力される場合があります。

2018-12-12T19:45:54+0900  DEBUG  ksocket.channel.session:_resume:213  Connecting to the peer. Wait 60.000000 seconds...
2018-12-12T19:45:54+0900  WARNING  ksocket.channel.session:_resume:225  Failed to start/resume session: [SSL: UNKNOWN_PROTOCOL] unknown protocol (_ssl.c:833). Wait 0 sec... [1/120]
2018-12-12T19:45:54+0900  DEBUG  ksocket.channel.session:_resume:213  Connecting to the peer. Wait 60.000000 seconds...
2018-12-12T19:45:55+0900  WARNING  ksocket.channel.session:_resume:225  Failed to start/resume session: [SSL: UNKNOWN_PROTOCOL] unknown protocol (_ssl.c:833). Wait 0 sec... [2/120]
2018-12-12T19:45:55+0900  DEBUG  ksocket.channel.session:_resume:213  Connecting to the peer. Wait 60.000000 seconds...
2018-12-12T19:45:55+0900  WARNING  ksocket.channel.session:_resume:225  Failed to start/resume session: [SSL: UNKNOWN_PROTOCOL] unknown protocol (_ssl.c:833). Wait 0 sec... [3/120]
2018-12-12T19:45:55+0900  DEBUG  ksocket.channel.session:_resume:213  Connecting to the peer. Wait 60.000000 seconds...

このときは、ksocket.yml に protocol: ws という接続方式を変更する設定が正しく読み込まれていません。上述の「ksocketの設定」の項を確認し、protocol行の設定を行いましょう。

「failed to connect server」と表示される

ksbridgeのログで、 failed to connect server と表示される場合、ksocketとksbridgeは疎通できていますが、ksbridgeとプロキシサーバ間の通信が確立できていない場合が考えられます。

$ ./ksbridge -bind 127.0.0.1:8080 -host yourspace.cloud.kompira.jp -proxy http://username:password@no.proxyserver.co.jp:3128
********************************************************************************
ksbridge - Tiny websocket connection bridge server

  listen: ws://127.0.0.1:8080/api/ksocket/connect
  server: wss://yourspace.cloud.kompira.jp/api/ksocket/connect
  proxy:  http://username:password@no.proxyserver.co.jp:3128

********************************************************************************
INFO[0012] connecting to client...
INFO[0012] client has connected
INFO[0012] connecting to server...
ERRO[0012] failed to connect server                      err="dial tcp: lookup no.proxyserver.co.jp on 10.10.10.0:53: no such host" uri="{wss   yourspace.cloud.kompira.jp /api/ksocket/connect  false  }"
INFO[0069] connecting to client...
INFO[0069] client has connected
INFO[0069] connecting to server...
ERRO[0069] failed to connect server                      err="dial tcp: lookup no.proxyserver.co.jp on 10.10.10.0:53: no such host" uri="{wss   yourspace.cloud.kompira.jp /api/ksocket/connect  false  }"

このような場合は、ksbridgeの実行時に指定しているプロキシサーバのサーバ名、アカウント、パスワードが正しいかどうかを確認してください。

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