クライアントサイトを数件管理する程であれば、インシデントにどれだけ迅速に対応できるかが重要になります。環境を把握していれば、通常すぐに解決することができます。また、トラブルに適切かつ迅速に対応することで、クライアントとの信頼関係がより強固になることもあります。迅速な対応力は、制作会社の成功を支える重要なスキルと言えます。
しかし、管理するサイトが増えるにつれて、発生するインシデントの数も増えていくものです。このとき、対応の速さだけに注力していると、問題を解決するスピードは向上しても、インシデントそのものの発生頻度は減りません。対応速度とインシデントの発生頻度は別の指標であり、この違いこそが、場当たり的な運用を続ける制作会社が大きなコストを抱える原因になります。
インシデント対応の速さだけを成功指標にすべきではない理由
管理サイトが1件、あるいは数件であれば、「問題が発生したら素早く解決する」という運用スタイルでも対応できます。インシデントの発生頻度が低く、環境も把握しやすいため、迅速な対応は重要なパフォーマンス指標になります。この指標はMTTR（平均修復時間）と呼ばれ、障害が発生してから復旧するまでに要する平均時間を示します。
しかし、管理するサイトが増えるにつれて、運用状況を評価するうえでより重要になるのがMTBF（平均故障間隔）です。先ほどのMTTRが「障害からどれだけ早く復旧できるか」を示すのに対し、MTBFは「次の障害が発生するまで、システムがどれだけ安定して稼働し続けるか」を示します。MTBFが長いほど障害は発生しにくく、短いほど障害が頻繁に発生していることを意味します。たとえ1件ごとの復旧がどれほど迅速でも、MTBFが短ければ、次々と発生する障害への対応に追われ続けることになります。
MTTRだけを改善しようとすると、障害からの復旧を早めることばかりに目が向き、肝心の障害そのものは減りません。MTTRは障害からどれだけ効率よく復旧できるかを示す指標です。一方、そもそも障害が発生しにくい運用になっているかを判断するには、MTBFを見る必要があります。
サイト数の増加によって顕在化する、MTBFの低さがもたらすコスト
管理サイト数が増えると、サイトごとのMTBFが短い環境では、インシデント対応が次々と発生し、対応スピードを上げるだけでは回らなくなっていきます。たとえば、以下のようなインシデントが複数のサイトで同時に発生することも珍しくありません。
- プラグインの更新による競合：管理サイト全体で共通のプラグインを利用している場合、アップデートによる不具合が複数のサイトで同時に発生する。
- ボットによるパフォーマンス低下：自動化トラフィックがキャッシュを回避し、大量のPHPスレッドを消費することで、複数のサイトが同時に影響を受ける。
- デプロイ時のミス：ステージング環境を経由する運用が徹底されていないと、設定ミスが本番環境に反映されてしまう。
- 共有インフラで発生する障害：サイト間の分離が不十分なサーバー環境では、1つのサイトで発生した障害が同じサーバー上のほかのサイトへ波及することがある。
こうしたインシデントの多くは、制作会社側に原因があるわけではなく、運用環境だけで防げるものでもありません。そのため、インシデントへの対応をいくら速くしても、発生件数そのものが減るわけではありません。
Kinstaを利用するHallは、数十年にわたりWeb制作・運用を手がけています。以前使っていたサーバーでは、アクセスが集中する時間帯にサイトのダウンが繰り返し発生し、WooCommerceサイトの売上に直接影響を与えていました。また、本来であればクライアント向けの業務に充てるべきチームの時間も、その対応に追われることになっていました。
Kinstaの考え方は、私たちの仕事の進め方と相性がいいです。私たちが求めるのは、予期せぬトラブルが起きない優れたパフォーマンスと、万が一問題が発生したときに頼れるサポートです。Kinstaのおかげでクライアント対応に追われることが減り、生産性が高まりました
インシデント管理では見えないコスト
制作会社は通常、インシデント対応にかかった工数、つまり開発者やアカウントマネージャーが原因調査や復旧に費やした時間をコストとして把握しています。しかし、実際にはインシデントには数字には表れないコストも存在します。
- コンテキストスイッチによる生産性の低下：開発者が構築中のプロジェクトを中断して本番環境のトラブル対応に入ると、元の作業に戻るまでに時間がかかる。調査によると、一度中断した作業で再び深く集中できるようになるまでには15〜25分程度かかるとされている。そのため、午前中に1件のインシデントが発生しただけでも、まとまった作業時間が失われることに。この時間はインシデント対応の記録には残らないが、管理するサイトが増えるほど積み重なっていく。
- クライアントからの信頼の低下：単発のインシデントであれば、透明性のある対応によって信頼関係を維持できるが、同じようなトラブルが繰り返し発生すると、「運用環境そのものに問題があるのではないか」という不安につながる。長期的な信頼を左右するのは、対応の速さではなく、インシデントの発生頻度。
- チームへの負担の増加：インシデント対応を前提とした運用では、シニア開発者が常に最前線で対応に追われることに。このような状態が常態化すると、人材の離職やリソース不足を招き、状況はさらに悪化していく。
管理サイトで繰り返し発生するインシデントへの対応に追われる状況は、人員不足ではなく、プラットフォームの問題であることが少なくありません。本当に必要なのは、継続的な対応を前提としなくても安定して運用できるインフラです。受賞歴を持つデジタルマーケティングエージェンシーParamarkも、Kinstaへ移行する前の環境を以下のように振り返っています。
サイトを安定して運用するには、過剰とも言えるほどのサーバー管理が必要でした。サーバーリソースの管理やログファイルの整理など、常に対応しなければならない作業があり、それを怠るとすぐにサイトが不安定になっていました
環境が本当に改善しているかどうかを判断するには、「復旧までに要した時間」ではなく、「サイトごとに1か月間で発生したインシデント件数」を追跡することが重要です。これにより、運用環境そのものが改善しているのか、それともチームが繰り返し発生する問題への対応に慣れただけなのかを見極めることができます。
インシデントを未然に防ぐ運用とは
Kinstaのインフラとプラットフォームは、この考え方をもとに設計されています。目指しているのは、インシデント発生後の復旧を速めることではなく、そもそもインシデントが起こりにくい環境を実現することです。
まず、各サイトは専用のソフトウェアスタックを備えた独立したLinuxコンテナ上で動作します。そのため、リソースがコンテナ間で共有されることはなく、同じ会社のアカウントに属するサイト同士であっても、互いに影響を受けることはありません。
制作会社で複数のサイトを運用する場合でも、各サイトは独立した環境で動作するため、1つのサイトで発生したインシデントが、ほかの管理サイトのパフォーマンスや可用性に影響を及ぼすことはありません。一方、共用サーバーでは、1つのサイトでリソース使用量が急増すると、同じサーバー上のほかのサイトまでパフォーマンスが低下する可能性があります。
自動バックアップとワンクリック復元
Kinstaでは、すべてのサイトの完全なバックアップが毎日自動で作成され、少なくとも14日間保持されます。コントロールパネルMyKinstaの「バックアップ」画面から、バックアップの確認や復元を行うことができます。また、以下のようなバックアップも標準提供しています。
- システムバックアップ：既存のバックアップからの復元など、重要な操作を実行する前に自動で作成されます。操作を開始する前には、必ず復元ポイントが作成されます。
- 手動バックアップ：必要なタイミングで最大5件までバックアップを作成できます。また、識別しやすいようにラベルを付けることも可能です。
各バックアップの横にある「復元先を選択」をクリックすると、そのバックアップを使って数回のクリックでサイトを以前の状態へ戻すことも可能です。また、Kinstaの自動アップデートアドンを利用して複数サイトを運用している場合は、更新を実行する前にシステムバックアップが自動で作成されます。そのため、更新後に問題が発生しても、まず復元してから原因を調査するという、一貫した手順で対応できます。どのサイトで問題が発生しても、同じ流れで復旧できるため、運用の予測性も向上します。
ステージング環境と選択的プッシュ機能
Kinstaのステージング環境では、本番サイトとは別にテスト用のコピーを作成できるため、変更内容をクライアントへ反映する前に安全に検証できます。すべてのKinstaプランには、サイトごとに1つの標準ステージング環境が無料で含まれています。
変更内容を本番環境へ反映する際は、選択的プッシュ機能を利用することで、どの変更を本番環境へ適用するかを細かく指定できます。
選択的プッシュを利用するには、MyKinstaでステージング環境を選択し、「別の環境に反映」をクリックした後、デプロイ対象（「ファイル」または「データベース」）を選択します。さらに、それぞれの項目のドロップダウンメニューから、反映する内容を細かく指定できます。
Kinstaでは、本番環境へプッシュする前に、対象環境の自動バックアップを必ず作成します。本番環境へのデプロイミスはインシデントの主な原因の1つですが、選択的プッシュとプッシュ前の自動バックアップを備えたマルチ環境構成を採用することで、本番環境で緊急対応が必要になる事態を防ぐことができます。
パフォーマンス低下を防ぐボット対策
Kinstaのボット対策機能は、WordPressがリクエストを処理する前の段階でボットをフィルタリングし、自動化されたアクセスによる負荷をインフラレベルで軽減します。これにより、サーバーのパフォーマンスへ影響が及ぶ前に対策を講じることができます。デフォルトでは、悪意のあるトラフィックと判定されたアクセスはプラットフォーム全体で自動的にブロックされます。
サイトごとの設定を変更するには、MyKinstaの「ボット対策」画面を開き、「対策レベル」セクションの「変更する」をクリックします。
4段階の対策レベルから選択可能で、デフォルトでは、DDoS攻撃や既知の攻撃元IPアドレスからのリクエストをブロックする「悪意のあるトラフィックをブロック」が適用されます。さらに、検証済みボットをブロックしたり、ボットの可能性が高いリクエストや分類できないリクエストを検証したりすることもできます。さらに、正当なボットとして検証されていないすべてのアクセスを検証する厳しい設定も可能です。これには、人間によるアクセスと判断されるリクエストも対象になります。
また、MyKinstaで複数のサイトを選択し、「操作」＞「ボット対策を変更」をクリックすると、複数のサイトに同じ対策レベルを一括で適用できます。ボットによるアクセスは、特にWooCommerceサイトや会員制サイトにおいて、キャッシュを回避してリクエストごとにPHPスレッドを消費し、サーバーへ大きな負荷をかける可能性があります。そのため、このような機能の重要性は今後ますます高まりそうです。
インシデントを未然に防ぐための分析機能
MyKinstaの分析機能では、問題がクライアントに影響を及ぼす前に、異常の兆候を把握できます。「分析」画面の「パフォーマンス」タブでは、PHPの応答時間やPHPスレッドの使用状況が時系列で表示されます。実際のユーザーによるアクセス数に大きな変化がないにもかかわらず、応答時間が長くなっている場合は、ボットによる負荷や非効率なデータベースクエリが原因である可能性があります。
これらの分析データは、サイトごとに数分確認するだけでも、事後対応だけでは見逃しがちな傾向を把握するのに役立ちます。
例えば、「プランご利用状況」の「訪問数」チャートでは、課金対象となる人間によるアクセス数がわかります。これを「上位リクエスト」タブの「アクセス数上位のリクエスト」チャート（自動化リクエストを含むすべてのトラフィックが対象）と比較することで、訪問数に大きな変化がないにもかかわらず、ボットによる負荷がサーバーのパフォーマンスへ影響を与えている状況を把握できます。
インシデントを未然に防ぐ運用への転換
インシデントの発生を減らすには、担当者の働き方を変えるのではなく、プラットフォームや機能の選択を見直すことが重要です。
例えば、インシデントが発生した際には、復旧手順だけでなく、サイトごとの要因もあわせて記録するようにしましょう。目的は記録そのものではなく、同じ原因によるインシデントが繰り返し発生していないかを把握することです。このような分析には、MyKinstaのログ機能が役立ちます。
同じサイトでプラグインの更新による競合が3回記録されていれば、ステージング環境を活用した運用プロセスに改善の余地があることが分かります。こうした記録がなければ、同じ問題が繰り返し発生していても、その傾向に気付くことはできません。
また、デプロイ前のチェックリストを用意しておくことで、これまでの運用で得た知見を標準化し、誰でも同じ手順で作業できるようになります。以下の項目を確認することで、多くのインシデントを未然に防ぐことができます。
- 本番環境に近い状態のKinstaステージング環境で、すべての変更をテストしてから本番環境へ反映する。
- 変更内容に応じて、選択的プッシュで適切なデプロイ対象を選択する。
- フォームや決済フロー、ログインエンドポイントなど、ユーザーが利用する動的機能を追加した場合は、「ボット対策」画面の設定を確認する。
- デプロイ後は「分析」画面の「パフォーマンス」タブを確認し、応答時間が通常の範囲内に収まっていることを確認する。
サイトごとのインシデントを継続的に記録すれば、問題が発生してから説明するのではなく、信頼性の改善状況を定期的に報告できるようになります。例えば、四半期ごとのレポートでインシデント件数が減少し、安定した稼働率を維持していることを示せれば、クライアントはトラブルのたびに連絡を受ける場合とは異なる印象を持ちます。
制作会社の成長を支えるのは、インシデントを未然に防ぐインフラ
インシデントへ迅速に対応する能力は、制作会社に欠かせません。しかし、事業規模が拡大するにつれて重要になるのは、その能力を常に発揮し続けることではなく、そもそもインシデントが起こりにくいインフラを整えることです。この違いが、収益性やチームの持続的な成長を左右します。
Kinstaの隔離コンテナ技術、バックアップシステム、ボット対策などの機能は、制作会社が多くの時間を費やしがちなインシデントの発生を抑えるよう設計されています。さらに、インシデントログやデプロイ前のチェックリストなどの運用プロセスを組み合わせることで、管理するすべてのサイトで継続的にインシデントを減らすことができます。
クライアントサイトを運用する制作会社向けには、エージェンシーパートナープログラムもご用意しています。大規模なWordPress運用を支援する専用ツールに加え、専任サポートや共同営業のための各種リソースも提供しています。
