この記事は「ひとりでカンファレンスふりかえりo0h Advent Calendar 2021」のday-4です。
ひとりでカンファレンスふりかえりo0h Advent Calendar 2021 - Adventar
今日振り返るのは、「エラーと向き合うアプリケーション運用」です。
PHP Conference Japan 2021のCfPに応募しました。Regular session (25 mins)の枠になります。
「アプリケーションエラーをしっかりと検知し、対処していこう」というのを、仕組み・ねらい・導入や運用・それで得られる効果についてお伝えしようとしたものです。
Sentryを利用しながら「どういう事ができるのか」についてお話します。それを組織内に導入して、「アラート、モニタリング」「課題管理、改善活動」に繋げていくための流れをイメージできるようになってもらえれば、と。
あわせて、「欠陥をすぐに取り除くか、もしくは時間が経過してから取り組むか」によって発生する対応コストの差分についても、所々の文献を引きながらお伝えしたいと思いました。
自組織において、「エラーを可視化して、定常的に対処していく」ようにしたいな〜できないかな〜と思ったのが当初のきっかけです。
(※ココでは「エラー = アプリケーションエラー」「欠陥」「不具合」「バグ」と同様の意味として、「エラー」に語を統一して扱います)
どんな話を(社内で)進めていけばいいのかな〜と考えていると、今の状態からそこまで進むのには恐らく様々なステップが必要そう・・・今すぐにはやれるものではないな？となったので、「じゃあ最終形(の一歩手前)までの青写真のようなものを、会社とは違う文脈を持つ場に出してみよう」となりました。
今までの自分の経験した環境を思い返してみると、意外とこの「エラーを常に潰し続ける、減らし続ける」という取り組みまで進めていた所は少なかったように感じます。よくあるのは、「エラー管理ツールを導入してはいるが、もう記録されているエラーが大量にある状態。どちらかというと放置気味」という状態でした。 面白いことに、最初に居た環境(開発者が自分を含めて1〜2人程度)、次に居た環境(同じく3人程度)、更にその次の環境(既にn*10名ほどが居る)でも同様でした。いわゆるスタートアップ系のステージが置かれる「エンハンス以外は全て後回し」の状態や、もしくは「その時のコードを引き継いでいる」ような所で、「検出されているエラーがたくさんある」のは仕方ないという向きもあるのかも知れません。しかしながら、「まだその時ほど余裕がないままか？」というと変わっている部分もあるはずで、では「なぜ減らないのか」「減らしていないからである」が本質のように感じます。
他方で、「3人程度の環境」が「プロダクトが少し安定してきて、人も多少増えた」あたりになってからは「エラーをグッと減らす」ところまで連れ出すことにも成功した事があります。そうして体感として知ったのは、「発生するエラーを極めて少なく保てているような状態では、障害やサービス遅延などは明らかに減る」ということです。 両者が直接的に関連するものかは知る由もないですが、「多少なり関係はありそう」「”割れ窓”を作らないことで守られるものがあるはず」とは直感しています。
自分が仕事において感じる「コードの質を保ちたい」というのは、こういうところを求めているのだと思います。それができていないのは苦しい。
「良い未来」に向かうのに最も必要なことは、「ちゃんと到達できる良い未来がある」と信じることです。 カンファレンス登壇という場を借りて、「これからの未来の話」をしてみたいなぁ〜・・・というのが、本プロポーザルの根底にある動機だと感じています。