Chatwork Android版アプリ 障害対応の舞台裏

「Chatwork」Android版アプリ 障害対応の舞台裏 奥澤 俊樹 @ 挑戦の軌跡をたどるAndroid開発の舞台裏 2025年3月11日

自己紹介 奥澤 俊樹（@okuzawats） 株式会社kubell所属 コミュニケーションプラットフォームディビジョン プロダ クト開発ユニット Androidアプリ開発グループ ビジネスチャット「Chatwork」 Android版アプリを作っ ています。 今年は前厄だと思って油断してたら本厄でした。

事業概要 ● 国内最大級のビジネスチャット「Chatwork」を展開。 業界のパイオニアであり国内利用者数No.1*1、導入社数は62.0万社*2を突破 ● 圧倒的な顧客基盤とプラットフォームを背景に、DXされた業務プロセスそのものを提供する クラウドサービス、BPaaSを展開 ビジネスチャット「Chatwork」 BPaaS (Business Process as a Service) お客様 *1 Nielsen NetView 及びNielsen Mobile NetView Customized Report 2024年4月度調べ月次利用者（MAU:Monthly Active User）調査。 調査対象はChatwork、Microsoft Teams、Slack、LINE WORKS、Skypeを含む41サービスを株式会社kubellにて選定。 *2 2024年12月末時点。 オペレーター

「Chatwork」Android版アプリ 障害対応の舞台裏

障害対応とは 障害 = システムにおいてユーザーの業務を妨げるもの※1 「Chatwork」で言えば、チャット等の機能を用いたコミュニケーション、またはそれを通 じた業務の遂行を妨げるもの※2 自分たちに直接の責任がないことが原因であったとしても、それは障害である。 例えば外部サービスの不調。 ※1 本スライドにおける説明のための定義。「Chatwork」及び株式会社kubellの公式見解ではありません。 ※2 本スライドにおける説明のための解釈。「Chatwork」及び株式会社kubellの公式見解ではありません。

障害対応とは 障害対応 ≠ 不具合を修正すること 障害対応 = 業務を遂行できる状態に復旧させること※1 不具合の修正は目的ではなく、手段の一つ。 「運用でカバーする」など、他の手段もあり得る。 ユーザーの業務が妨げられている状態から早期に復旧させることが重要。 ※1 本スライドにおける説明のための定義。「Chatwork」及び株式会社kubellの公式見解ではありません。

障害対応の流れの要点 障害検知 ・ユーザー問い合わせ ・エラーログ ・Velocity Alert ・etc… 障害対応 ・リリース停止 ・関係者招集 ・対応方針策定 ・復旧作業実施 ・ストア申請 ・障害収束判定 ふりかえり （ポストモーテム） ・場作り ・事実関係の整理 ・根本原因の抽出 ・改善アクションの策定 ・改善アクションの実施 7

障害検知の流れ ユーザー様か らの問い合わ せ 障害ではない 社内からの問 い合わせ インシデント 障害 判定 エラーログ Velocity Alert ユーザーの業務は遂行できるか？ ユーザーの業務にどの程度影響があるのか？ ・機能の重要度 ・機能の利用者数 ・回避方法の有無 ・etc… 障害

障害対応時の役割分担 障害対応はエンジニア中心に実施する。エンジニアの役割を2つに分担する。 - - インシデントコマンダー - 障害発生・収束の宣言、対応方針決定等、障害対応に関する意思決定 - 作業担当者への指示、作業の優先順位付け - 関係者の招集・意見取りまとめ・連絡 - 情報整理 作業担当者 - 原因調査・影響範囲調査・対応方針策定 - 原因調査と影響範囲調査は2人以上で分担できることが望ましい - 技術領域に詳しい者 - インシデントコマンダーへの報告 - リリース関連作業 木村 (2024), 「改訂新版 システム障害対応の教科書」を元に、現状の我々のグループの状況を整理。用語も木村による。

障害対応の流れ 作業担当者 影響箇所・範囲の 調査 当該バージョンの リリースを停止 原因調査 hotfix （修復・切り戻し） 修復方針策定 ストア申請 指示・報告 障害発生 宣言 情報整理 対応方針決定 インシデント コマンダー 関係者の招集 （チャット、ビデオ通話） 取りまとめ エラーロ グ 障害収束宣言 広報連携 ユーザー様への周知

障害対応 インシデントコマンダーが不在・役割が不明確だと何が起こるか？ - 障害検知から障害対応への移行に時間がかかってしまう。 - 障害発生の宣言の欠如 障害対応に入った後、方針や責任が曖昧なまま、復元時間が伸びていく。 - 指揮命令系統の混乱 - 情報伝達の不備 - 意思決定者と作業者の境界不在 障害対応は緊急性を伴うため、平時と比較して現場のマネジメントの重要性が高い。 インシデントコマンダーを立て、指揮命令系統を確立することにより、最短で復元する。

※ サービス復元時間の推移 約40%の短縮 当初、障害発生時の役割分担が曖昧で、 サービス復元時間が伸びがちであった。 インシデントコマンダーとして振る舞うことで、 サービス復元時間を短縮することができた。 ただし、インシデントコマンダーを設置して関 係者を巻き込んだ対応が必要になるような障 害対応は、Androidアプリに関しては年に1回 か2回程度。 画像出典： https://creators-note.chatwork.com/entry/2024/12/18/175518

• https://creators-note.chatwork.com/entry/2024/12/18/175518

ふりかえり（ポストモーテム） 障害対応をふりかえり、再発防止のための改善アクションを抽出する。 - - - ポジティブな雰囲気となる場作り - 非難なし（no blame）ルール - 責任追及の場になってしまうと、問題を隠してしまう 時系列で事実関係を整理 - 障害対応中に考えたこと、判断に迷ったことの言語化も大切 根本原因の抽出 - なぜなぜ分析等の手法 改善アクションの策定 - KPT等の手法 - 精神論はダメ - プロセス・ツールの改善 改善アクションの実施 - 二度と同じ障害を出さないという断固たる決意でやり切る

ふりかえり（ポストモーテム） 時系列で事実関係を整理 改善アクションの策定 根本原因の抽出

現状の課題 - インシデントコマンダーが属人化している。 - 障害はひとつひとつ異なるため、教育が難しい。 - - 自分も誰かに教わったわけではない。 - 障害は計画できないため、意図して経験を積むことができない。 - 障害対応訓練を行うこともできるが、実施コストが高い。 モバイルアプリの場合、手作業による修復作業、アプリの申請・承認、ユーザーによる アプリのアップデート、というようにユーザーが障害から回復するまでのタイムラグが 長い。 - 動的にフィーチャーをトグルすることで、このタイムラグを短縮することが可能な ケースも多いと考えている。 - 疎結合アーキテクチャやインフラの整備等、前提条件が多く、途上。

まとめ - 障害は、システムにおいてユーザーの業務を妨げるものである。 - 障害対応は、ユーザーが業務を遂行できる状態に復旧することである。 - 障害対応は、以下の流れで行う。 - - 障害検知 - 障害対応 - ふりかえり（ポストモーテム） 障害発生時、インシデントコマンダーと作業担当者の役割を分担し、意思決定者・指揮 命令系統を明確にした上で、インシデントコマンダーが障害対応現場のマネジメントを 行うことで、サービス復元時間の短縮につながる。 - インシデントコマンダーの育成は課題である。 - 動的にフィーチャーをトグルすることで、ユーザーが障害から回復するまでの時間を短 縮できる可能性がある。

参考文献 - - 木村誠明, (2024), 「改訂新版 システム障害対応の教科書」, 技術評論社 ふりかえりカタログ / Retrospective Catalog, retrieved from https://speakerdeck.com/viva_tweet_x/retrospective-catalog-59bd3a29-314c45dd-911b-f8e5f1308333 （最終アクセス日：2025年3月11日） Androidアプリ開発部の「four keys」大公開！赤裸々な1年を振り返る, retrieved from https://creators-note.chatwork.com/entry/2024/12/18/175518 （最終アク セス日：2025年3月11日）

• https://speakerdeck.com/viva_tweet_x/retrospective-catalog-59bd3a29-314c-45dd-911b-f8e5f1308333
• https://creators-note.chatwork.com/entry/2024/12/18/175518

働くをもっと楽しく、創造的に 18