ビジネスの拡大で増えるアラートに対処していくためには
ココナラでは、川崎氏が入社する以前の2016年からPagerDutyを活用している。導入の経緯について川崎氏は「2016年当時はおそらくエンジニアの人数は10名から20名程度でした。24時間・365日の安定稼働を実現するには多くの人数が必要ですし、アウトソースするにもコストがかかります。SaaSのPagerDutyなら費用対効果が高いと判断したのではないでしょうか。私も前職で、PagerDutyを費用対効果を鑑みて、同じような理由で採用しました」と説明した。
コミュニケーションツールとして使っているSlackにアラートの通知を送っているものの、即座に対応するための架電というアクションにつなげにくいし、外部委託のコストもかけたくない。そこでPagerDutyに各種アラートの発報を任せ、DatadogやAmazon CloudWatch、Sentryなどの監視ツールとも連携して、優先度を見極めた発報が行われている。川崎氏は「PagerDutyがなかったら相当つらいです。私たちにとって、なくてはならないシステム運用を支えてくれるソリューションのひとつです」と述べた。
ビジネスが拡大していくに従って、システム運用やインシデント対応の役割も重要さを増す。リリースの速度が増えると不具合が起きる確率も高まる。エンジニアも増えているのでナレッジの共有も課題となっている。そもそもどんなアラートを発報するかといったエラーの扱いも試行錯誤が必要だ。アラートを鳴らして誰かが気づけばいいというスタンスでは、不必要なアラートが増える一方だ。
そこで川崎氏は、オンコール当番だけに負担がかからないように担当エンジニアもアラートを気に掛けるといった運用の工夫をしている。オンコール当番のオンボーディングのためにTipsのデータベースを構築したり、インシデント対応を効率化するためのランブック（作業手順書）を拡充したりする地道な活動を続けてきた。
「しっかりアラートの内容を確認して、これは本当に発報するべきなのかをPagerDuty側に設定し、フィルターをかけていますので、既知のエラーでスルーしてもいいものは発報せず、未知のものと対応が必要なものだけを発報するようにしています。PagerDutyで検知した内容をフックしてAWS Lambda経由でランブックを流すこともしています。このような運用を愚直に行い、積み重ねています」（川崎氏）。
