Insinyur SRE - Intern
Pertama, izinkan saya memperkenalkan diri. Saya @ tristan.read , seorang insinyur front-end di Monitor :: Grup kesehatan GitLab. Minggu lalu, saya merasa terhormat menjadi pekerja magang dengan salah satu insinyur SRE kami yang bertugas. Tujuannya adalah memonitor setiap hari bagaimana petugas merespons insiden, dan mendapatkan pengalaman kerja yang nyata. Kami ingin teknisi kami lebih memahami kebutuhan pengguna fitur Monitor :: Health.
Saya harus mengikuti insinyur SRE di mana-mana selama seminggu. Yaitu, saya menghadiri tugas shift, menonton saluran notifikasi yang sama dan menanggapi insiden, jika dan ketika itu terjadi.
Insiden
Selama seminggu 2 insiden terjadi.
1. Cryptominer
Pada hari Rabu, GitLab.com melihat lompatan dalam penggunaan GitLab Runner , yang disebabkan oleh upaya untuk menggunakan menit pelari untuk menambang cryptocurrency. Kami menangani insiden dengan menggunakan alat kami sendiri untuk menetralisir pelanggaran, yang menghentikan tugas pelari dan menghapus proyek dan akun yang terkait dengannya.
Jika peristiwa ini tidak diperhatikan, alat otomatis akan menangkapnya, tetapi dalam kasus ini, insinyur SRE adalah yang pertama kali memperhatikan pelanggaran. Tugas insiden dibuat, tetapi informasi tentangnya sudah ditutup.
2. Degradasi kinerja aplikasi Canary dan Main
Insiden itu dipicu oleh perlambatan dan peningkatan tingkat kesalahan dalam aplikasi web kenari dan utama di Gitlab.com. Beberapa nilai Apdex telah dilanggar.
Tugas insiden terbuka: https://gitlab.com/gitlab-com/gl-infra/production/issues/1442
Temuan Kunci
Berikut adalah beberapa poin yang saya pelajari selama minggu tugas.
1. Peringatan paling berguna ketika kelainan terdeteksi.
Lansiran dapat dibagi menjadi beberapa jenis:
- Peringatan berdasarkan nilai ambang tertentu seperti "10 kesalahan 5xx per detik" terjadi.
- Peringatan di mana ambang adalah nilai persentase dari jenis "frekuensi kesalahan 5xx per 10% dari total volume permintaan pada waktu tertentu."
- Lansiran berdasarkan rata-rata historis dari tipe “5xx kesalahan pada persentil ke-90”.
Secara umum, tipe 2 dan 3 lebih berguna untuk tugas SRE, karena mereka mengungkapkan penyimpangan dari norma dalam proses.
2. Banyak peringatan tidak pernah meningkat menjadi insiden
Insinyur SR berhadapan dengan aliran peringatan yang konstan, banyak di antaranya tidak terlalu kritis.
Jadi mengapa tidak membatasi peringatan hanya untuk yang sangat penting? Namun, dengan pendekatan semacam itu, seseorang tidak dapat mengenali gejala awal apa yang akan tumbuh, seperti bola salju, menjadi masalah nyata, mengancam kerusakan besar.
Tugas SRE yang bertugas adalah menentukan peringatan mana yang benar-benar mengatakan sesuatu yang serius, dan apakah peringatan itu perlu ditingkatkan dan mulai dipahami. Saya menduga ini juga disebabkan oleh tidak fleksibelnya peringatan: akan lebih baik jika beberapa level atau cara "pintar" mengatur peringatan diperkenalkan sesuai dengan situasi yang dijelaskan di atas.
Saran fitur: https://gitlab.com/gitlab-org/gitlab/issues/42633
3. Petugas SRE kami menggunakan banyak alat.
Internal:
- Proyek infra GitLab: Runbooks tinggal di sini, shift bergilir / minggu, tugas respons insiden.
- Masalah GitLab: Investigasi, penguraian, dan pemeliharaan juga dilacak dalam tugas.
- Label GitLab: tugas otomasi diluncurkan menurut label tertentu, yang digunakan bot melacak aktivitas tugas.
Eksternal:
- PagerDuty: Peringatan
- Slack: Aliran pesan PagerDuty / AlertManager ada di sini. Integrasi dengan perintah slash untuk melakukan berbagai tugas, seperti menutup peringatan atau meningkatkan insiden.
- Grafana: visualisasi metrik dengan fokus pada tren jangka panjang.
- Kibana: memberikan visualisasi / pencarian di majalah, kemampuan untuk menggali lebih dalam pada acara-acara tertentu.
- Zoom: Ada "ruang diskusi" yang berfungsi di Zoom. Ini memungkinkan para insinyur SRE untuk dengan cepat mendiskusikan berbagai acara tanpa membuang waktu yang berharga untuk menciptakan ruang dan tautan bagi para peserta.
Dan masih banyak lagi.
Jika pemadaman layanan utama terjadi pada GitLab.com, kami tidak ingin ini memengaruhi kemampuan kami untuk menyelesaikan masalah. Itu bisa dihentikan dengan menjalankan instance GitLab kedua untuk menginstal GitLab.com. Sebenarnya, ini sudah berfungsi untuk kita: https://ops.gitlab.net/ .
5. Beberapa fitur yang perlu dipertimbangkan saat menambahkan ke GitLab
- Pengeditan tugas multi-pengguna mirip dengan Google Documents. Ini akan membantu dengan tugas-tugas insiden selama acara tersebut, serta tugas parsing. Dalam kedua kasus, beberapa peserta mungkin perlu menambahkan sesuatu secara langsung.
- Lebih banyak webhook untuk tugas. Kemampuan untuk menjalankan berbagai langkah alur kerja GitLab dari dalam akan membantu mengurangi ketergantungan pada integrasi Slack. Misalnya, kemampuan untuk mengaktifkan notifikasi di PagerDuty melalui perintah slash dalam tugas GitLab.
Kesimpulan
Insinyur SRE mengalami kesulitan dengan banyak kesulitan. Alangkah baiknya melihat lebih banyak produk GitLab dalam menyelesaikan masalah ini. Kami sudah mengerjakan beberapa penambahan produk yang akan memudahkan alur kerja yang disebutkan di atas. Detail tersedia di bagian Visi Produk Ops .
Pada tahun 2020, kami memperluas tim untuk mengumpulkan semua fitur hebat ini. Jika tertarik, silakan baca lowongan , dan jangan ragu untuk menghubungi seseorang dari tim kami untuk pertanyaan.