ホーム

スタッフブログ

2022年2月10日

他サービスのシステム障害を、真剣に考える(2)

こんにちは

システムチームマネージャー / プログラマーのAです。

前回に引き続き、他サービスのシステム障害を取り扱います。

 

一応、

前置きとして、

システム障害に関わった開発者さんには、深く同情していますし、

エンドユーザーさんを、とても気の毒に思っています。

 

晒しものにしたいわけではなく、

具体的な事例を、自分事としてインプットすることで、

失敗の数を減らし、嫌な思いをする人が減ればと思っています。

 

 

IT特化型Q&Aサイト「teratail」リプレイスに失敗

2022/01/12(水)午前7時。

teratailの「機能見直し」によるシステムメンテナンスが実施されました。

 

2度の予定変更(遅延?)後のメンテナンスとなり、

メンテナンス完了後には

「モックの値が表示されている!」といったような

通常、あり得なさそうな障害報告が相次ぎました。

 

終いには

「teratail 不具合報告」という記事で、

teratail内にteratailの不具合がまとめられることになります。

 

 

メンテナンス内容は「言語の変更」

公式アナウンスはされていませんが、

今回のメンテナンス内容は、バックエンド言語の変更 が有力です。

PHP(CakePHP2)=>JavaScript(Next.js) に変更されたそうです。

 

CakePHP2をAPI的に使っていたかどうか、で話が変わりますが、

いずれにしても、高難易度の仕事です。

個人的には、決死の覚悟が要ります。

 

 

システム障害は、人為的に起こり得る

多数の障害報告の中には、

技術的なミスが原因ではない、障害がありました。

 

・知ってたけど、遅延してるからリリース強行するしかなかった

・そもそも改修項目から漏れていた

といった

人為的なミスから発生したようなものです。

 

そして、

最もダメージの大きい、人為的なミスが

「差し戻せる状況を作っていなかった」

ことにあると、個人的には考えています。

 

 

差し戻しは行われなかった

今回のメンテナンス後、

致命的な障害報告が多数ありましたが、

差し戻しは行われませんでした。

 

修正対応速度、

障害報告の多さ的に、

十分、差し戻しに値するレベルの状況だと思いますが、

おそらく、

何らかの原因で「差し戻せなかった」のだと思います。

 

例えば

・メンテナンス前後で、保持データの構造が不可逆になっている

・差し戻す手順を作っていない、分からない

・予算的に、差し戻しの承認を取っていない

のような原因です。

 

これらは

技術的なミスではなく、人為的なミスになります。

 

 

ダメージを回復できない事が、最大のダメージ。

 

先月の京都大学の件もそうでしたが、

ダメージを回復できないことが、最大のダメージ

だと自分は考えています。

 

差し戻せない、リリースも、

修正できない、不具合も、

抹消できない、個人情報の流出も、

全て同じく、回復できない。

 

回復が出来るミスは良いんです。

回復が出来ないミスは、絶対にしてはいけない。

 

自分は

メールやチャットの誤字にうるさいんですが、

そういう所が理由の1つだったりします。

取り消せないメール送信も、同じことです。

 

 

再発防止策を考えてみる

恐れ多いですが、

今回も再発防止策を考えてみようと思います。

社内で作成する、リリース手順の参考になればと思います。

 

 

① DNS切替のみで、リリースを完了する

 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄

詳しく言うと…

新サーバーを用意

→ 新サーバー上に、新バックエンド環境を構築。

→ ドメインの向き先を切り替えて、リリース完了

 

という手順になります。

 

差し戻しはDNSを切り替えるだけで済みます。

 

今回の様な

言語の変更に伴っては、

・新ミドルウェアのインストール、設定調整

・旧ミドルウェアのアンインストール

など、時間が必要な工程が多数存在します。

 

そういう場合は

一旦別のサーバーに新環境を構築し、

ドメインの向き先を変えるだけにしておく

が安全なリリース方法の1つだと思います。

 

旧サーバーの削除は、

新環境上で安定した後で良いですし、安心です。

 

 

② 段階的なリリースを検討する

 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄

言語変更の様な大規模なリリースに際して、

1度で全てリリースする事は難しいです。

 

であれば

いくつかの段階に分け、

リリースすることを検討してもいいかと考えます。

 

例えば

新旧バックエンド言語で併用可能な、フロントエンドの構築

→ 新旧バックエンド言語で併用可能な、インフラの構築

→ バックエンド言語のリプレイス

→ 旧バックエンド言語のみで利用するミドルウェアの削除

 

等が思いつきます。

1度に多くの問題を解消することは難しいです。

であれば、細切れにして、

順次解消していく、という発想でもいいですね。

 

—–

情報が少ないので、

実現不可能な内容かもしれませんが、

今回は、これらしかないかな、という感じです。

 

「ファイル・データを更新する」以外にも、

リリースの手順はあるというアイデアが大事かなと思います。

 

今回は以上となります。

 

参考資料

 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄

「teratail 不具合報告」

https://teratail.com/questions/36leqkyeq9nzih

 

「teratailもりあがっtail? 82問目」

https://medaka.5ch.net/test/read.cgi/prog/1639190782/#860

 

「ITエンジニア向けQ&Aサイト「teratail」、システムメンテナンス後バグだらけサイトになる | スラド IT」

https://it.srad.jp/story/22/01/17/2210200/

 

 

 

 

 

 

 

求人バナー

このページの上部へ戻る