昨日、故障しないシステムは現実的ではないので、故障を前提に計画を立てるべきだと頭の整理をしました。ただし、故障システムをすぐに復旧させるように動く事は大事ですし、それをどうやって見つけるべきなのか、改めて勉強してみました。
具体的なプロトコルやソフトの使い方ではなく、大きな指針やポリシーなどの設計者の方にいい本じゃないかと思います。
■備忘メモ
●監視は大きく5つの要素で構成される。
-データ収集
-データ保存
非常に大規模な容量になるので、容量を削減するログローテションを使用する。
例、残しておいてもその粒度では使わないデータを平均値で丸める。
(1週間経過したデータは1分単位から、10分の平均でまとめて保存する)
-可視化
グラフ化して時系列の推移を確認するなど。
-分析・レポート
-アラート
●監視の優先度はユーザに近い所が高い。
できるだけユーザに近い所から監視を行う。ユーザへのサービス提供が正常に継続できているなら大きく問題ではなく、逆にそうでないならすぐに対応すべきなため。
監視しやすい所やインフラ装置の深い所からではなく、ユーザに近い所から監視を始める事の方がよい。
●監視や改善に必要な情報がとれるアプリであること
そもそも測定できなければ、監視も改善もできない。
速度メータがない車や燃料タンクメータがない車では、速度違反やガス欠ばかりでまともに走れない。もし、必要なデータが取れないならば、追加すべき。
●監視や異常検知のAI利用
あくまで一例ですが、正常な動いてるデータをAIに学習させて、AI活用して現在のシステムが正常か異常で判定する仕組みもでているようです。
おそらくは、「正常な状態」を学習させておいて、そこから「一定以上外れている状態」は正常ではないから異常だと判断させるのかなと思います。異常パターンは無数にある上に実際の異常が起きる回数は多くないので(はず・・・)、AI学習に資するデータ量をとれないと考えてました。一杯とれるであろう正常パターンなら学習できる量あるんじゃないかな~と思います。
■Tips
観察者効果は気にするな、という表現がありました。これは、観察する機能をいれる事で対象の処理が重くなってしまう事を指していましたが、ハード性能が十分に向上した今のご時世には気にしなくてよいレベルの負荷との事です。
※IoTとかの超小型チップとかは、今でも考慮が必要でしょうが・・・一般的なサーバやPCや装置でも気にしなくてよそさうですね。
あと、健康診断の例も面白いですね。どこのどこの指標値が高いから改善しよう!といわれた際に、その値だけでは見ても改善は困難で、お酒や砂糖の取りすぎなど根本の原因の所を監視しておかないと改善できないよとの趣旨がありました。
これこそ、CPU利用率やメモリ等の値を監視するだけで満足せずに、ユーザに近い所でサービス提供できているかどうかを監視せよという所につながりますね。
※まあ、勿論監視対象は、しっかりオペレータが見切れる範囲において多くの箇所をとるに越した事はないでしょうが。とるだけとっておくが、普段は見せないようにして何かトラブル時に詳細解析しておくように保存はしておく方がいいんですかね。
・ANAの例(2016年)
世界初のSWバグのせいでシステム中断、3億6000万の機会損失
ただし、eラーニング等のBCP訓練は年1回していたので、システムが使えずとも手作業で業務遂行していた。
https://xtech.nikkei.com/it/atcl/watcher/14/334361/041100532/?P=3
システム設計がいけてないとの声もありますが、ちゃんと従業員が訓練されているの強みですね。