これはGoアドベントカレンダー3の8日目の記事です。
外部のAPIと連携して仕事をするサービスを長年運用・開発しています。 エラーが発生しある仕事が完了できないことがあり、その場合はエラーレポートを見て手動対応します。 なるべく運用負荷を減らすため、エラーの自動対応を進めていく過程で見つけた方針・実装テクがあるので紹介します。
ポイント
- 一時的なエラー、恒久的なエラーのあいだにはグラデーションがある
- エラー自身にエラー対応をさせると複雑さが減る
エラーのグラデーション
エラーハンドリングの記事を探すと、func Temporary(err) bool で一時的なエラーか判別してリトライをかますのをよく見ます。
一時的なエラーとは例えばネットワークのTimeoutなど。時間をおけば自動的に回復ししそうなもの。
それ以外はぜんぶ恒久的(Permanent)なエラーとしてレポートを上げてしまう。
実際に運用していると上がってきたエラーにはなにか対応が必要なので手を取られてしまいます。 可能ならば自動対応してエラーレポートしないようにしたい。
運用をつづけていて一時的なエラーと恒久的なエラーのあいだに次のようなエラーの種類があることに気づきました。
- そのままではリトライしても成功しないけれど、何かの操作をすれば成功する状態に持っていける回復可能なエラー。
- どうやってもリトライ成功にはできないけど、失敗した状況をマシにしたり詳細なレポートを作れるフォロー可能なエラー。
単に一時的なエラーかそうでないかだけでなく、これらを区別してハンドリングすることで成功率を上げて手動対応を減らすことを目指します。
| 区分 | 自動対応 | レポート | 説明 |
|---|---|---|---|
| 一時的 | 可 | 不要 | |
| 回復可能 | 可 | 不要 | なにか操作することで回復可能 |
| フォロー可能 | 不可 | 必要 | 回復不能だがより良い状態に出来る |
| 恒久的 | 不可 | 必要 |
