![見出し画像](https://assets.st-note.com/production/uploads/images/98051061/rectangle_large_type_2_5621c232710510f42656b349a0a10207.png?width=1200)
noteのシステムメンテナンスから考えるシステムメンテナンス
今日の日本時間の午前6時、noteのメンテナンスが無事に完了したようです!(しかも6時ぴったりに!!)
エンジニアの端くれである私としては、裏で働かれていた全てのエンジニアの方にお疲れ様でしたと拍手を送りたいです。
このnoteでは、noteのシステムメンテナンスから考えるシステムメンテナンスについて書いてみたいと思います。(禅問答)
システムメンテナンスって何してるの?
今回のnoteのシステムメンテナンスでは、具体的に何の変更があったのか分からないので想像に基づいた話しかできませんが、よくあるシステムメンテナンスの理由としては
新バージョンのアプリケーションの適用(アップデート)
セキュリティパッチの適用
バグの修正
新機能の適用
裏のアーキテクチャの変更(DB移行など)
コンプライアンス基準、セキュリティ基準の適用(FedRAMP, HIPAAなど)
などが挙げられます。
…と書いてる間にnoteのエンジニアさんの技術記事を見つけました。マガジンに色々なテーマで纏まっていてとても面白そうです!!フォローさせていただきました。今回のシステムメンテナンスの概要についてもいつか報告があるのでしょうか。(わくわく)
クラウドサービスにメンテナンスはつきもの
クラウドサービスにメンテナンスはつきものです。また、メンテナンスに伴うダウンタイムもつきものです。(ダウンタイム=システムが使えなくなる時間のこと)
noteに限らず、クラウドサービスを利用しているユーザーは、裏のシステム構成や稼働状況を一切気にせずに、提供されているサービスに集中して利用することができます。
それは、裏でエンジニアたちが背後にあるシステム構成をチェックし、稼働状況をモニタリングし、ボトルネックになっている部分がないかを監視してくれているからなのです。
上記のようなメンテナンスが発生する場合には、どうしてもシステムを一時的に停止しないといけない場合があります(身近な例では、iPhoneのiOSアップデートの際にも再起動が走りますよね)それが、今回のnoteのシステムメンテナンスだったと考えています。
ちなみに、私の本職はクラウドサービスのセールスエンジニアですが、ごくたまに「メンテナンスでサービスが止まるなんておかしいでしょ!ちゃんと24時間365日使える状態にしてくれないと!(怒)」と言ってくるお客様がいます。
SLA*が無いのにそのようなことを言ってくる方には、システムメンテナンスの理由やクラウドサービスを稼働させるために必要であるという重要性をお伝えします。(SLAで規定されている場合は別です)
それでもゴニョゴニョ言ってくるお客様には、それではどうぞクラウドサービスの利用をお辞めになって、別途用意しているオンプレのサービスをご自身で運用管理なすってくださいとお伝えしています。
ちなみに、noteにSLAは適用されていないはずなので、理論上はnoteは、いつ、何度でもシステムメンテナンスを実施できることになります。あくまで理論上は、です。それが現実的でない理由は後述します。
※SLAとは?
Service Level Agreementのこと。サービスの提供事業者とその利用者の間で結ばれる、サービスのレベル(定義、範囲、内容、達成目標等)に関する合意のこと。一般的にBtoBの金銭的契約が絡むシステムの提供時に出てくる。
メンテナンスが実施される日時
よほど緊急性の高いメンテナンスでない限り、一般的な定期メンテナンスの場合は事前にユーザーに告知があり、利用者に最も影響がない日時・時間帯を選んで実施されます。
なので、今回のnoteのシステムメンテナンスもある程度一般的な定期メンテナンスの類だったのではと推測しています。
時間帯が午前1-6時だったのは分かりますが、面白いなと思ったのは、曜日が水曜日だったということです。水曜日はユーザー活動が一番少ないのでしょうか。noteのユーザー動向の統計を見たことが無いので推測ですが、面白かったです。週の半ばでみんな疲れちゃうんですかね。
ちなみに、業務システムの場合、緊急性が求められるメンテナンスでない限り、ほぼ必ず週末にシステムメンテナンスが予定されます。担当者になった場合は週末にオフィスで缶詰になって仕事をすることになります。
メンテナンスにかかる時間
今回のnoteのダウンタイムはちょうど5時間でした。私はアメリカにいるので日本時間の朝6時前からサイトをチェックしていて、いつ復旧するかな〜というのを眺めていました。そして朝6時ぴったりに、サイトが復旧したのを確認しました。
さて、この5時間は一体どこから来たのでしょうか?noteのエンジニアさん達が、「なんか知らんけど、5時間くらいかかるんちゃう?」とどんぶり勘定で決めたのでしょうか?
いえいえとんでもない。この5時間という数字は、エンジニアさん達の並々ならぬ努力とシミュレーションと度重なる試算によって算出されたものであるはずです。
ダウンタイムが長ければ長いほど、noteは企業として利益創出の機会を失います。経営陣にとって、それは避けたい事態です。
かといって、本当に作業に必要な時間より短い時間を提示してしまうと、当日になってメンテナンスが間に合わず、告知時間よりオーバーしてしまうことになります。すると予定時刻になってもサービスが使えず、ユーザーからの不満が溜まり、評判にも悪影響を及ぼします。最初に工数を見積もっていなかったので、いつ復旧するか分からない事態にもなり兼ねません。
そのため、ダウンタイムの算出に関しては「短すぎず、長すぎず、メンテナンスに必要な時間をピッタリと予測する」必要があるのです。その予測をするためには、メンテナンスに必要な工数を正確に見積もり、不測の事態に対応する時間も含めた、精緻な試算が行われています。
5時間見積もっていて、早く終われば早めに復旧させることもできたでしょうから、予定時間の午前6時ちょうどに復旧したところを見ると、ギリギリ全ての作業がおさまったという感じなのかな、と勝手に推測しています。お疲れ様でした!
noteのエンジニアさん、ありがとうございます
いつも楽しいサービスを使わせて頂いていて本当にありがとうございます!noteは使いやすくて、UIも可愛くて、随所に継続執筆を促す工夫がされていてとても気に入っています。これからも頑張ってください🤗!!
最後までお読みいただきありがとうございました!
スキ・フォローよろしくお願いします☺
この記事が気に入ったらサポートをしてみませんか?