Insinyur SRE - peserta pelatihan
Pertama, izinkan saya memperkenalkan diri. SAYA - , insinyur front-end di grup GitLab. Minggu lalu saya mendapat kehormatan untuk magang dengan salah satu insinyur SRE panggilan kami. Tujuannya adalah untuk mengamati bagaimana petugas yang bertugas menanggapi insiden sehari-hari dan mendapatkan pengalaman nyata dalam pekerjaannya. Kami ingin teknisi kami lebih memahami kebutuhan pengguna Pantau::Kesehatan.
Saya harus mengikuti insinyur SRE kemana saja selama seminggu. Artinya, saya hadir pada saat serah terima, memantau saluran peringatan yang sama dan merespons insiden jika dan ketika terjadi.
Insiden
Ada 2 insiden dalam seminggu.
1. Penambang Kripto
GitLab.com mengalami lonjakan penggunaan pada hari Rabu 'a, disebabkan oleh upaya untuk menggunakan menit pelari untuk menambang cryptocurrency. Insiden tersebut ditangani menggunakan alat netralisasi pelanggaran kami sendiri, yang menghentikan tugas runner dan menghapus proyek serta akun yang terkait dengannya.
Jika kejadian ini tidak diketahui, alat otomatis akan menangkapnya, namun dalam kasus ini, teknisi SRE mengetahui pelanggaran tersebut terlebih dahulu. Tugas insiden telah dibuat, namun informasi tentangnya ditutup.
2. Penurunan kinerja aplikasi Canary dan Utama
Insiden ini disebabkan oleh perlambatan dan peningkatan frekuensi kesalahan pada canary dan aplikasi web utama di Gitlab.com. Beberapa nilai Apdex dilanggar.
Buka tugas insiden:
Temuan Kunci
Berikut beberapa hal yang saya pelajari selama seminggu bertugas.
1. Peringatan paling berguna saat mendeteksi penyimpangan dari norma.
Peringatan dapat dibagi menjadi beberapa jenis:
- Peringatan berdasarkan nilai ambang batas tertentu, seperti “10 kesalahan 5xx terjadi per detik”.
- Peringatan dengan ambang batas berupa nilai persentase seperti “frekuensi kesalahan 5xx per 10% total volume permintaan pada waktu tertentu”.
- Peringatan berdasarkan rata-rata historis seperti "kesalahan 5xx pada persentil ke-90".
Secara umum, tipe 2 dan 3 lebih berguna untuk SRE yang sedang bertugas, karena mereka mengungkapkan penyimpangan dari norma dalam prosesnya.
2. Banyak peringatan yang tidak pernah meningkat menjadi insiden.
Insinyur SR menangani aliran peringatan yang terus-menerus, banyak di antaranya sebenarnya tidak penting.
Jadi mengapa tidak membatasi peringatan Anda hanya pada peringatan yang benar-benar penting saja? Namun, dengan pendekatan ini, Anda mungkin tidak mengenali gejala awal dari apa yang akan menjadi masalah nyata yang mengancam kerusakan besar.
Tugas SRE yang siap dihubungi adalah menentukan peringatan mana yang benar-benar mengindikasikan sesuatu yang serius, dan apakah peringatan tersebut perlu dieskalasi dan ditangani. Saya menduga hal ini juga disebabkan oleh tidak fleksibelnya peringatan: akan lebih baik jika ada beberapa level atau cara “pintar” untuk mengonfigurasi peringatan sesuai dengan situasi yang dijelaskan di atas.
Saran Fitur:
3. SRE kami yang bertugas menggunakan banyak alat.
Intern:
- Proyek infra GitLab: runbook ada di sini, tugas shift/minggu, tugas respons insiden.
- Masalah GitLab: Investigasi, peninjauan, dan pemeliharaan juga dilacak dalam masalah.
- Label GitLab: Tugas otomatisasi diluncurkan menggunakan label tertentu, yang digunakan bot untuk melacak aktivitas tugas.
Luar:
- PagerDuty: Peringatan
- Slack: Alur pesan PagerDuty/AlertManager ada di sini. Integrasi dengan perintah garis miring untuk melakukan berbagai tugas, seperti menutup peringatan atau meningkatkan insiden.
- Grafana: visualisasi metrik dengan fokus pada tren jangka panjang.
- Kibana: Memberikan visualisasi/pencarian log, kemampuan untuk menggali lebih dalam peristiwa tertentu.
- Zoom: Ada “ruang breakout” yang terus berjalan di Zoom. Hal ini memungkinkan teknisi SRE mendiskusikan acara dengan cepat tanpa membuang waktu berharga untuk membuat ruangan dan menghubungkan peserta.
Dan banyak banyak lainnya.
4. Memantau GitLab.com dengan GitLab adalah satu titik kegagalan
Jika GitLab.com mengalami gangguan layanan besar-besaran, kami tidak ingin hal itu memengaruhi kemampuan kami untuk menyelesaikan masalah tersebut. Hal ini dapat dihentikan dengan meluncurkan instance GitLab kedua untuk mengelola GitLab.com. Faktanya, ini sudah berhasil bagi kami: .
5. Beberapa fitur yang perlu dipertimbangkan untuk ditambahkan ke GitLab
- , mirip dengan Google Dokumen. Hal ini akan membantu tugas-tugas mengenai insiden selama suatu acara, serta tugas-tugas pembekalan. Dalam kedua kasus tersebut, beberapa peserta mungkin perlu menambahkan sesuatu secara real time.
- Lebih banyak webhook untuk tugas. Kemampuan untuk menjalankan berbagai langkah alur kerja GitLab dari dalam akan membantu mengurangi ketergantungan Anda pada integrasi Slack. Misalnya, kemampuan untuk mengizinkan peringatan di PagerDuty melalui perintah garis miring di masalah GitLab.
Kesimpulan
Insinyur SRE mengalami kesulitan dengan banyak kerumitan. Senang rasanya melihat lebih banyak produk GitLab mengatasi masalah ini. Kami sedang mengerjakan beberapa tambahan pada produk yang akan membuat alur kerja yang disebutkan di atas lebih mudah. Detail tersedia di .
Kami memperluas tim pada tahun 2020 untuk menyatukan semua fitur hebat ini. Jika tertarik, silakan periksa , dan jangan ragu untuk menghubungi siapa pun di tim kami jika ada pertanyaan.
Sumber: www.habr.com