監視・運用を担当するエンジニアにとって、作業事故や障害は避けることはできません。
本記事では、2023年12月5日にクラスメソッドにて発生した作業事故について、エンジニアの視点から良い点・悪い点について考察します。
クラスメソッドが起こした障害事故の概要
はじめに、クラスメソッドの障害事故概要について見ていきましょう。
2023年12月5日、クラスメソッドが運用するAWS環境で発生した障害は、セキュリティ上の懸念から特定のAWSアカウント群を一時的に隔離しようとした際、作業者の操作ミスにより広範なAWSリソースが操作不能となる事態を引き起こしました。
具体的には、AWS Orgnaizationsで管理されているアカウント群に対して、新しく作成された組織ユニット（OU）へアカウントを移動し、そのアカウントに対して全ての操作を禁止するサービス制御ポリシー（SCP）を適用する作業を行う予定でした。
しかし、誤ってAWS Organaizations内のRootに対して本ポリシーを適用したことが原因です。
これにより、AWS Orgnaizations内全てのアカウントに対してIAM権限がはく奪され、AWS操作不能に陥ってしまいました。
現役エンジニアからみる本事故の悪かった点
クラスメソッドの障害事故において、個人的に悪かった点についてご紹介します。
平日の日中帯にやるべき作業ではなかった
本作業・障害が発生した2023年12月5日は、平日の日中帯（17時頃）でした。
この時間帯は、多くの企業がAWSサービスを利用しており、障害の影響が拡大しやすい状況です。
理想的には、緊急性が低い場合、メンテナンス作業は利用者の少ない夜間や週末に行うべきでした。
実際私が勤めていた企業でも、影響が大きい作業や危険作業についてはユーザーの利用が少ない深夜1時~5時で実施していました。
しかしながら、監視・運用をメインに行っていない企業にとっては深夜帯に人員を用意することも難しい企業もあるかと思います。
その場合は、後述するサーバー管理のアウトソーシングなどをするべきでしょう。
事故速報の展開が遅かった
今回の時系列では、2023-12-05 17:15に障害が発生し、2023-12-05 17:51に障害速報を展開していました。
障害発生から約36分後に速報をHP上に公開していることになります。
迅速な情報共有は、顧客の信頼を保持し、不安を最小限に抑えるために不可欠です。
また、顧客からの架電を抑えるという点でも効果的です。
今回のようにAWSが利用できなくなった際、まず顧客は担当営業やカスタマーサポートに電話を行います。その時に電話が集中し電話サポートがパンクしたり、通常のサービスを提供できなくなってしまいます。
障害知得から10分程度を目安にHP公開するべきだったと言えます。
お客様起因で障害に気づいた
今回の障害は、お客様の架電により知得しています。
理想的には、サービス提供者側が最初に問題を検知し、即座に対応を開始すべきでした。
お客様起因で気づいてしまうと、お客様側のサービスに対する不信感が上がってしまいます。また、炎上・重クレームにつながるケースにもなります。
できる限り障害に関しては自社で検知できるような仕組み作りが大切です。
また、作業員も作業手順書内に正常性確認項目を入れておくべきだったと思います。危険作業の実施前後に、想定される挙動となっているか確認する項目が必要でした。
特別対応ほどエラーは起きやすい
この障害事故は、特定の顧客要求に基づく特別な対応の過程で発生しました。
特別対応、特に緊急時の対応は、プロセスから逸脱することが多く、エラーが発生しやすくなります。
事故発生の根本原因は、普段の作業では実施していない不慣れな作業だったはずです。
このような特別対応が必要とされる状況では、慎重な手順書作成と有識者による承認、作業のダブルチェックが特に重要です。
現役エンジニアからみる本事故の良かった点
クラスメソッドの障害事故では問題点も多く見られましたが、同時に評価できる対応もありました。
障害知得から原因特定・解決までの時間が早い
障害知得後、原因特定～解決までの速さは迅速でした。
実際、2023-12-05 17:27 ~ 17:40の13分間で特定から復旧まで行っています。
障害発生から原因の特定、そして対策の実施に至る迅速な対応は、顧客の信頼回復に不可欠です。
このような素早い反応は、予め整備された内部のプロセスと、高度な技術力があってこそ可能になります。
障害管理においては、速やかな原因解明が重要であり、クラスメソッドのこの対応は、素晴らしかったと言えるでしょう。
障害発生時には作業員も普段のメンタルとは違い、パニックとなってしまいます。
手順書内に切り戻し手順や異常時対応の項目を盛り込むことが大切です。
原因の深堀・再発防止策ができている
障害の原因を徹底的に分析し、再発防止策を講じたことも評価できます。
クラスメソッドは、事故報告書にて詳細な分析結果と、具体的な再発防止策を公開しました。
この透明性の高い対応は、顧客との信頼関係を維持し、将来的な障害リスクを減らす上で非常に効果的です。
また、ISOの規格にも十分に則った対応と言えます。
再発防止策を具体的に策定し、公開することで、他のAWSユーザーにも有益な情報を提供しています。
このような開かれた姿勢は、業界全体の知見の蓄積に貢献し、より強固なクラウド環境の構築へと繋がります。
障害が起きた際には、その原因を深掘りし、根本から解決を図ることが重要です。クラスメソッドの対応は、多くの企業にとって参考になるはずです。
まとめ
クラスメソッドの障害事故は、AWSを使用する上で起こりうるリスクとその対処方法について、多くの教訓を提供しています。
障害が発生した場合の迅速な対応、透明性のあるコミュニケーション、そして再発防止策の徹底は、すべてのITプロフェッショナルが学ぶべきポイントです。
この事故を通じて、エンジニアは障害管理の重要性と、顧客への責任を再認識することができます。
AWSの使用を検討している企業や、現在利用している企業にとって、このような事例は価値ある学びであり、より安全で信頼性の高いクラウドサービスの利用へと繋がるでしょう。
このように、障害対応は迅速・正確性が必須で、深夜作業には人員も必要です。
自社で監視体制を構築せず、サーバーの管理をアウトソーシングする方法もあります。
アイレット株式会社では、AWSサーバーの運用監視を24時間365日フルサポートで行っています。
このようなサーバー管理会社を有効活用し、社員のライフワークバランスの向上に取り組むことをおすすめします。
AWSサーバーの監視運用を24時間365日でご支援！【AWS運用・保守サービス】
