可用性

Availability

IT運用

システムが障害やメンテナンスなどで停止することなく、ユーザーが「いつでも正常に利用できる状態」を継続して維持する能力や度合いのこと。

🐾 猫で例えると？

ソファーで仰向けに眠る茶トラ。そばにいてほしいときに、そこにいてくれる安心感を、必要なときに利用できるサービスへ重ねてみます。可用性は、決めた条件で要求を満たせる度合いです。猫も休息するように、実際の運用では必要な時間帯や、どの停止をどう評価するかを決めます。

可用性は、情報セキュリティの3大要素「CIA（機密性・完全性・可用性）」の1つに数えられる非常に重要な指標です。どんなに素晴らしい機能を持ったWebサービスでも、「アクセスしようとしたらサーバーが落ちていて使えない」という状態が頻発すれば、ユーザーはすぐに離れてしまいます。

稼働時間の割合で測る場合、365日を24時間すべて測定対象にした99.99%は、停止時間が年間約52.6分に相当します。一方、成功したリクエストの割合で測るサービスもあります。測定期間、成功の条件、計画停止の扱いを決めてから比較します。

可用性を高めるための基本戦略は「冗長化（予備を用意すること）」です。サーバーを1台だけでなく複数台用意して負荷を分散（ロードバランシング）したり、データベースをクラスター構成にして常に同期させたりすることで、どこか一部のハードウェアが壊れても、システム全体としては動き続けるように設計します。

障害時に予備系へ切り替えるのがフェイルオーバーです。安全な状態へ移すフェイルセーフは、必要ならサービスを停止することもあり、同じ意味ではありません。可用性を確認するには、機器の応答だけでなく利用者が主要な操作を完了できるかを見ます。

# Linuxなどのpingで、ICMP応答だけを確認する例
if ping -c 3 192.168.1.100 > /dev/null; then
    echo "ICMP応答あり（アプリの正常性は別途確認）"
else
    echo "ICMP応答なし（遮断や通信障害も調査）"
fi

pingが通ってもログインや保存が失敗する場合があります。逆に、ICMPを遮断していてもWebサービスは動く場合があります。HTTP応答や重要な操作の監視を追加し、単発のping失敗だけで切り替えないようにします。

何でもかんでも稼働率100%を目指せば良いというわけではありません。可用性を高めるほど、予備のサーバー代や運用コストが跳ね上がります。現場では以下のポイントでバランスを取ります。

目標と合意を区別する：内部の運用目標はSLO、顧客とのサービス水準や未達時の扱いを定める合意はSLAです。必要な水準から構成や対応体制を決めます。
単一障害点（SPOF）をなくす： 「ここが壊れたらシステム全体が止まる」という弱点（例：ネットワークの出入り口のルーターが1台しかない等）を見つけ出し、そこから優先的に冗長化を図ります。
計画停止の扱いを決める：更新や保守に必要な時間を確保し、停止を測定値に含めるかも明示します。利用者への案内や、停止を短くする手順と合わせて運用します。

茶トラがそばにいてほしいときにいてくれる安心感を、サービスでは測れる条件に置き換えます。必要な時間帯と許容できる停止時間を決め、監視と復旧の手順を整えましょう。冗長化した構成でも、実際に切り替わることを確かめる必要があります。