今週月曜日に都内で発生した雪。普段ならリモートワークで家から出ないのですが、諸事情により出社。帰宅時に雪の中、雷が鳴る雷雪（らいせつ）という珍しい気象事象に遭遇することができました。ここまでくると寒いとか辛いという感情よりもレアな体験をしたというポジティブ感情が勝りました。
数日前から都内で雪が予報されていたこともあり、電車が運転見合わせで帰宅できないのでは、という不安がありましたが、多少の遅延はあれどほとんど正常に運行していたおかげで無事に帰宅できました。雪と雷の荒天候の中、運行に努めていただいた各電車会社には感謝しかありません。
私たち電車利用者にとって、時刻通りに電車が来るのが当たり前だという認識が多いです。運転見合わせや遅延があれば容赦なく叩かれます。しかし、「時刻通りに電車を運行する」という利用者にとっての当たり前を維持しつづけるのはとても大変なことだと思われるのです。
時刻表通りに駅に着くように運転する技術は当然ながら、大勢の乗客が乗り降りや乗客同士のトラブル、線路や列車などの機械トラブルなど遅れる多数の要因をできるかぎり解消するための運用も必要でしょう。私たち利用者が見えない裏側で電車運行を支えてくれている人たちも含めると、「当たり前」なことを運用するために膨大な人的コストと金銭的コストがかかっていることでしょう。
今の私の仕事のロールはSRE（Site Reliability Engineering; サイト信頼性エンジニアリング）というものです。サイト（WEBサイト、WEBサービスなど）に対して高い可用性と信頼性を維持し、ユーザーに対して提供するアプローチのことでGoogleが最初に導入しました。
「信頼性」とは、簡単にいえば利用ユーザーにとって当たり前なことを維持することです。
例えば、YouTubeで動画を見るときどういう操作をしますか？ブラウザからYouTubeにアクセスして見たい動画を選んで再生ボタンを押しますよね。「そんなの当たり前じゃないか」と思いますが、その「当たり前」を一定レベルに維持するように務めるのがSREの役割です。
他の例を挙げます。Amazonで商品を注文したときに、次の「当たり前」なことを要求されます。
- ユーザーが注文した商品が倉庫にあり、かつ不良品でないこと
- 商品を倉庫から間違えずピックアップし包装する
- 配達員が指定された住所に間違えず、指定された日時に配達する
Amazonの在庫管理システム、倉庫内オペレーション、配送システムのいずれかが信頼性を損なうとユーザーに商品が届きません。つまり、これらすべてのシステムを総合して信頼性を維持する必要があります。
さて、信頼性をKPIとして評価するために数字化が必要です。これをSLI/SLOという指標を定める必要があるのですが、どんなサービス・商品でも100%の信頼性を約束することはほとんど不可能であり、非現実的です。その理由は次回のブログに書きます。
