信頼性のさじ加減

土曜の朝、カレッジフットボールをひたすら見るだけの何にもしない一日を楽しもうとカウチに座り込むと、やると約束してから2週も先送りにしていた落ち葉の片付けがあると妻に言われた。善良な地域住民でありたいし、HOA に違反したくなかった (HOA: 住宅街の家主向けの住宅管理規約。自宅の芝刈りを怠るなど違反すると罰金を徴収される)。テキサスロングホーン試合もなかったので、熊手を持って外へ出た。

fall leaves

たくさんの落ち葉があった。庭の100%が落ち葉に覆われていたと思う。落ち葉を熊手でかき集めながら、そこそこの労力で、落ち葉の90%を5つの山にまとめることができた。そして、落ち葉の山をゴミ袋に入れた。

庭はずっと見栄えがよくなったが、まだたくさんの葉が落ちている。熊手もある。袋もある。すでに外にいるし、汚れてもいる。庭全体にもう一度熊手をかけて、残りの10%の落ち葉も片付けることにした。最初の90%のときと同じくらい時間がかかったが、同じ達成感は得られなかった。落ち葉の山はさっきほど大きくなかったのに、その山の90%程度の落ち葉を袋に入れられただけだった。これで落ち葉の99%は片付けることができた。

まだ充分日は高く、もう少しきれいに出来ると思ったので、残りの1%の落ち葉も取ることにした。これを読んでいる皆さんがご存じかどうかわからないが、葉っぱが一枚だけの方がすべりやすく、つかみづらい。熊手でかき集められるくらいの量がないときは、2回も3回も、あるいは4回も同じ場所に熊手をかけて、葉っぱを集めることになる。庭に3回も熊手をかけるのはより時間がかかる作業だが、残り1%の落ち葉の90%を片付けることができた。つまり、庭の落ち葉の99.9%は片付けられたことになる。

庭に座り、ほぼ落ち葉がなくなった様を見てうっとりしていると、熊手で取り切れなかった葉や、木から落ちてきたばかりの葉が目に入った。数は多くはないが、そこにあった。良い仕事をしたくて、私は庭で四つんばいになり、落ち葉を1枚ずつ拾い始めた。ご想像どおり、この作業は退屈で、庭全体を見て回るには長い時間が必要だったが、残りの0.1%の90%は片付けることができた。この時点で、99.99%の落ち葉を片付けられていた。

日が沈み始め、もはや落ちているのは、ピンセットでしか拾えないような葉っぱのかけらだけだった。

家の中に入り、妻に「ピンセットはどこかな ?」と聞くと「フェンスのペンキ塗りに、どうしてピンセットがいるの ?」と聞かれた。「フェンスのペンキ?」と私は思った。そうだ、今日はフェンスのペンキ塗りもすると約束していたのだった。フェンスにはまだ何も手を付けられていないし、明日はカウボーイズの試合だからこの週末には出来ない、と私は妻に伝えた。妻は不満そうだった。

わざとらしく聞こえるかもしれませんが、この話には、Indeed がシステムの信頼性と新機能のベロシティの管理に取り入れているポイントがよく表れているのです。

私はどこで間違えたのか?

私が間違いをおかしたのは、ピンセットを持ってくることを考えた時点よりもずっと前でした。落ち葉拾いを始める際に、きれいに掃除された庭の定義を曖昧なままにしてしまっていたのです。どれくらいのパーセンテージなら、庭に落ち葉が残っていてもクライアントが掃除された庭とみなしてくれるのかを具体的に示すサービスレベル目標 (SLO) を決めていませんでした。

SLO を定義しておくべきだったのか?

SLO を前もって定義しておくことはできたでしょうが、自分が達成できる数値に基づいて決めていたかも知れません。私は、ピンセットでしか拾えないような葉っぱのかけらまで拾い、99.999%の落ち葉を片付けることができました。テキサスロングホーンの試合がある週末だったら、90%の落ち葉を拾えればよしとしていたかもしれません。

SLO は、SLO を気にしているクライアントに決めてもらうべき

先ほどの私の話では、クライアントは HOA と妻になります。予定より長い時間をかけても、庭の落ち葉の50%しか片付けられていない場合、HOA から通知が来ます。妻は、年に一度、落ち葉の99%を片付けてくれれば満足だと言っています。SLO としては、この2つの基準のより高い方が選ばれるでしょう。私は99%の落ち葉を拾えた2ラウンド目で落ち葉拾いをやめ、フェンスのペンキ塗りをする時間を確保できていたでしょう (ペンキを何層塗るかという SLO 次第ですが)。

でも、良い仕事をしましたよね?

確かに良い仕事はしましたが、定義しなかった99%という SLO を0.99ポイント上回ったにも関わらず、報われませんでした。妻は、やり過ぎた1%分をほめてくれるどころか、もう1つの頼みごとであったフェンスのペンキ塗りの時間がなくなってしまったことに腹を立ててしまったのです。

この話から、次のような教訓を得ました。

適切な SLO を定め、それを越える努力をすべきだが、やり過ぎるべきではない

SLO を「ユーザーのニーズ」だと定義した場合、Indeed では、それを上回るための努力は避けるようにしています。そして、節約した労力を、より多くの機能を迅速にデプロイ し、信頼性とベロシティのバランスを維持することにあてています。


投稿者の紹介

Andrew Ford は、Indeed の site reliability engineer (SRE) で、データベースの信頼性と拡張性などの問題に楽しんで取り組んでいます。カレッジフットボールのシーズンが始まり、東海岸の全試合が終わる9月から12月の間の土曜日は、ほとんどカウチにいます。

クライアントのニーズにあった SLO の定義に興味がある皆さん、Indeed の SRE の採用情報をご覧ください。

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on RedditEmail this to someone