もしステークプールにトラブルが起きてしまったら？
奇抜倶楽部ステークプール管理⼈、YOWZAです。
今回はステークプールの障害対応について記します。
みなさんの中にもシステムトラブルに遭遇された⽅もいらっしゃるかもしれません。最近話題になっている、みずほ銀⾏のシステム障害などがその一例です。急いでいるときにATMからキャッシュカードや通帳が取り出せず、その場から離れられないといった目に遭ってしまったら⾮常に厄介ですよね。
エイダコインのステーキングに関しては、もし万が一ステークプールに障害が発生したとしても、エイダコインが出金できなくなることはないのでご安⼼ください。
ITサービスマネジメントの世界では、企業や組織が提供するITサービスがシステムの不具合により正常に利⽤できない、またはサービスの品質や利便性が損なわる障害を「インシデント」と呼びます。
みずほ銀行の例でいうと、以下のようになります。
- ATMからキャッシュカードや通帳が取り出せない！ → インシデント発生
- 障害発生のアナウンス、障害内容の特定、対応、一時的な改善 → インシデント管理
インシデント管理では、可能な限り迅速に通常のサービス品質に復旧するための改善を行います。インシデントを発生させた要素は問題管理として管理されます。問題管理では、根本原因の解消を目指します。
みずほ銀行の場合は、新基幹システム「MINORI」をマルチベンダー（富士通、日立製作所、日本IBM、NTTデータ）へ分割発注したことと、前身3行（第一勧業銀行、富士銀行、日本興業銀行）の旧システムが混在していることもあり、すべてを把握するのは不可能と思いますし、問題管理で発生原因を管理したとしても、根本原因を取り除くことは相当難儀であることが想像できます。
インシデント管理について
インシデント管理の流れは、以下の通りです。
- ① インシデントの受付
- ② インシデントの分類・優先度の設定
- ③ 担当者もしくは上位部署への引き継ぎによるインシデントの解消
- ④ インシデントの回答
- ⑤ インシデントの解決とクローズ
それぞれの内容は以下になります。
① インシデントの受付
サービス利用者からの問い合わせや、障害管理システムからのアラートを受けて、窓口担当者やアラートの管理者が受付を行います。
② インシデントの分類・優先度の設定
過去に同様の事例がないかデータベースを確認し、内容や影響範囲に応じて緊急度や優先度を設定します。
最初に問い合わせを受けた担当者レベルで解決できないと判断した場合、上位部門へ引き継ぎます。
③ 担当者もしくは上位部門への引き継ぎによるインシデントの解消
対応が容易なもの（マニュアル化されたもの）は、インシデントの受付を行った担当者が対応します。
担当者では対応できないインシデントは、上司や責任者へ引き継ぐことでインシデントの解決にあたります。
④ インシデントの回答
インシデントが解消された後、問い合わせユーザーに回答し、システムの利用者に周知します。
⑤ インシデントの解決とクローズ
インシデントを解消した記録をデータベースに登録します。データベースに登録後、適宜、他の担当者に共有を行います。また、経過の観察が必要なインシデントは、その対応が終了するまでインシデント管理を継続します。
ステークプールでのインシデント管理の例
ステークプールを運営していく上でのインシデント管理の例としては、ブロックプロデューサーノードやリレーノードのサーバーダウンや、CPUやメモリー使⽤率の⾼負荷によるシステムダウンが挙げられます。
事前に予知可能な障害は、障害発⽣時にメールやLINEに通知されるように事前に設定しておきます。
通知を受けるとインシデント管理の業務フローに基づき、インシデントの受付から始まり、インシデントの解決とクローズまで流れるようにイメージしています。大きな会社のシステムであれば、それらは全て分業となるので業務フローや報告を明確にする必要がありますが、「奇抜倶楽部ステークプール」は私ともう一人のメンバーだけで運営していますので、
ガチガチにフローを遵守する必要はありませんが、私自身普段は大規模のITインフラの管理運営も行っているので、どうしてもフローどおりにしたいと思ってしまいます。
もし既出でない障害が発生した際は、それが頻繁に起こりうるものなのかどうかを検討し、今後も起こりうる可能性の高いものであれば、対策を検討します。例えば、カルダノノードのプログラムのバージョンが上がることでメモリ使⽤率が向上したことにより、プログラムが頻繁にダウンするなどの障害が発⽣する場合は、恒久対策として物理的なメモリを増加させるといった措置を取るといった具合です。
「奇抜倶楽部ステークプール」では幸いなことに今まで一度も障害は発生していませんが、
今後もし発生した際はITILに沿った形で対応をし、速やかに復旧できるような準備は心がけています。
「奇抜倶楽部」は、安⼼・安全で堅牢なステークプールを今後も維持していきます。
「奇抜倶楽部」ティッカー名:KIBA への委任を、ぜひよろしくお願いします！
ITILについての補足
前回、今回とご紹介したITIL（Information Technology Infrastructure Library）ですが、ITIL v2 / ITIL v3 / ITIL 4と新たな内容を盛り込みながらバージョンを上げています。
ITIL v2 では、「プロセスアプローチ」と「ベストプラクティス」が大きな特徴としてあげられます。プロセスアプローチとは、業務をプロセスという単位に分け、横断的に管理し、プロセスごとの役割と責任を明確にしていきます。2006年にJ-SOX（金融商品取引法に定義される内部統制報告制度）が制定された際に、上場企業では、受発注処理や請求処理などのワークフローをExcelのワークシートに描画するといった業務フローの整備に明け暮れました。プロセスアプローチとは、その時の業務フロー作成に近しいです。もう一つのベストプラクティスは、実在の企業に適用されていて、効果のあった事例についての紹介になります。
ITIL v3 では、サービスインフラにとらわれず、ビジネスと見立てた戦略的なガイダンスが盛り込まれています。サービス提供における「ライフサイクル・アプローチ」の概念を採用しているのが特徴です。サービスを継続していくには、顧客からの需要を把握し、利益を上げていく必要があります。このようなビジネス的な観点が含まれています。
