SRE エンジニア - 研修生
まず、自己紹介をさせていただきます。 私 - , グループ内フロントエンドエンジニア GitLab。 先週、私は光栄なことに当社のオンコール SRE エンジニアの XNUMX 人とインターンをすることができました。 目的は、当直警察官が日常的に事件にどのように対応するかを観察し、実際の勤務経験を積むことでした。 当社のエンジニアにはユーザーのニーズをより深く理解してもらいたいと考えています モニター::ヘルス。
私は XNUMX 週間、どこにでも SRE エンジニアについて行かなければなりませんでした。 つまり、私は引き継ぎに立ち会い、同じ警報チャネルを監視し、インシデントが発生した場合には対応しました。
事件
2週間以内にXNUMX件の事件がありました。
1. 暗号通貨マイナー
GitLab.com は水曜日に使用量が急増しました 'a、ランナーの時間を使用して暗号通貨をマイニングしようとする試みによって引き起こされます。 このインシデントは、ランナーのタスクを停止し、それに関連付けられているプロジェクトとアカウントを削除する独自の違反無効化ツールを使用して対処されました。
このイベントが気づかれなかった場合は、自動ツールがそれを捕らえていたでしょうが、この場合は SRE エンジニアが最初に違反に気づきました。 インシデントタスクが作成されましたが、それに関する情報は閉じられています。
2. Canary アプリケーションと Main アプリケーションのパフォーマンスの低下
このインシデントは、Gitlab.com 上のカナリアおよびメイン Web アプリケーションの速度低下とエラーの頻度の増加が原因でした。 いくつかの Apdex 値が違反されました。
インシデントタスクを開く:
主な調査結果
ここでは、一週間の勤務中に私が学んだことをいくつか紹介します。
1. アラートは、標準からの逸脱を検出する場合に最も役立ちます。
アラートはいくつかのタイプに分類できます。
- 「10 秒あたり 5 個の XNUMXxx エラーが発生しました」など、特定のしきい値に基づいてアラートを生成します。
- しきい値が「特定の時点でのリクエストの総量の 5% あたりの 10xx エラーの頻度」などのパーセンテージ値であるアラート。
- 「5 パーセンタイルでの 90xx エラー」などの過去の平均に基づくアラート。
一般に、タイプ 2 とタイプ 3 は、プロセスの標準からの逸脱を明らかにするため、勤務中の SRE にとってより有用です。
2. 多くのアラートはインシデントにエスカレーションすることはありません。
SR エンジニアは、絶え間なく発生するアラートに対処しますが、その多くは実際には重要ではありません。
それでは、アラートを本当に重要なものだけに限定してみてはいかがでしょうか? ただし、このアプローチでは、雪だるま式に深刻な被害をもたらす実際の問題に発展する初期の症状に気づかない可能性があります。
オンコール SRE の仕事は、どのアラートが実際に何か重大なことを示しているのか、そしてそれらのアラートをエスカレーションして対処する必要があるかどうかを判断することです。 これはアラートの柔軟性の低さも原因ではないかと思います。上記の状況に応じてアラートを構成するための複数のレベルまたは「スマートな」方法があれば、より良いでしょう。
機能の提案:
3. 勤務中の SRE は多くのツールを使用します。
内部：
- GitLab インフラ プロジェクト: ランブックはここにあり、シフト/週の割り当て、インシデント対応タスク。
- GitLab の問題: 調査、レビュー、メンテナンスも問題で追跡されます。
- GitLab ラベル: 自動化タスクは、ボットがタスクのアクティビティを追跡するために使用する特定のラベルに基づいて起動されます。
外部の：
- PagerDuty: アラート
- Slack: PagerDuty/AlertManager メッセージ フローがここに進みます。 スラッシュ コマンドとの統合により、アラートのクローズやインシデントへのエスカレーションなど、さまざまなタスクを実行できます。
- Grafana: 長期的な傾向に焦点を当てたメトリクスの視覚化。
- Kibana: 視覚化/ログ検索、特定のイベントをより深く掘り下げる機能を提供します。
- Zoom: Zoom には常に実行されている「ブレイクアウト ルーム」があります。 これにより、SRE エンジニアは、ルームの作成や参加者のリンクなど貴重な時間を無駄にすることなく、イベントについて迅速に議論できるようになります。
他にもたくさんあります。
4. GitLab を使用した GitLab.com の監視は単一障害点です
GitLab.com で大規模なサービス停止が発生した場合、問題を解決する能力に影響が及ぶことは望ましくありません。 これを停止するには、GitLab.com を管理する XNUMX 番目の GitLab インスタンスを起動します。 実際、これはすでに機能しています。 .
5. GitLab への追加を検討すべきいくつかの機能
- 、Googleドキュメントに似ています。 これは、イベント中のインシデントに関するタスクや報告会に関するタスクに役立ちます。 どちらの場合も、複数の参加者がリアルタイムで何かを追加する必要がある場合があります。
- タスク用の Webhook の追加。 さまざまな GitLab ワークフロー ステップを内部から実行できるため、Slack 統合への依存度を軽減できます。 たとえば、GitLab の問題でスラッシュ コマンドを使用して PagerDuty でアラートを許可する機能です。
まとめ
SRE エンジニアは、多くの複雑さに苦労しています。 これらの問題に対処する GitLab 製品がさらに増えることを願っています。 私たちはすでに、上記のワークフローを容易にする製品へのいくつかの追加に取り組んでいます。 詳細は次のサイトで入手できます .
これらの優れた機能をすべて統合するために、2020 年にチームを拡大します。 興味のある方はぜひチェックしてみてください ご質問がございましたら、お気軽にチームの誰にでもお問い合わせください。
出所： habr.com