Jurutera SRE - pelatih
Pertama, izinkan saya memperkenalkan diri saya. saya - , jurutera hadapan dalam kumpulan GitLab. Minggu lepas saya mendapat penghormatan untuk berlatih dengan salah seorang jurutera SRE atas panggilan kami. Matlamatnya adalah untuk memerhatikan cara pegawai yang bertugas bertindak balas terhadap insiden setiap hari dan memperoleh pengalaman sebenar di tempat kerja. Kami ingin jurutera kami lebih memahami keperluan pengguna Monitor::Kesihatan.
Saya terpaksa mengikut jurutera SRE ke mana-mana selama seminggu. Iaitu, saya hadir pada penyerahan itu, memantau saluran amaran yang sama dan bertindak balas terhadap insiden jika dan apabila ia berlaku.
Kejadian
Terdapat 2 kejadian dalam masa seminggu.
1. Pelombong Crypto
GitLab.com menyaksikan lonjakan penggunaan pada hari Rabu 'a, disebabkan oleh percubaan untuk menggunakan minit pelari untuk melombong mata wang kripto. Insiden itu telah ditangani menggunakan alat peneutralan pelanggaran kami sendiri, yang menghentikan tugas pelari dan memadamkan projek serta akaun yang dikaitkan dengannya.
Jika peristiwa ini tidak disedari, alat automatik akan menangkapnya, tetapi dalam kes ini, jurutera SRE menyedari pelanggaran itu terlebih dahulu. Tugas insiden telah dibuat, tetapi maklumat mengenainya ditutup.
2. Kemerosotan prestasi aplikasi Canary dan Utama
Insiden itu disebabkan oleh kelembapan dan peningkatan kekerapan ralat dalam kanari dan aplikasi web utama di Gitlab.com. Beberapa nilai Apdex telah dilanggar.
Tugas insiden terbuka:
Penemuan Utama
Berikut adalah beberapa perkara yang saya pelajari sepanjang minggu saya bertugas.
1. Makluman adalah paling berguna apabila mengesan penyelewengan daripada norma.
Makluman boleh dibahagikan kepada beberapa jenis:
- Makluman berdasarkan nilai ambang tertentu, seperti "10 5xx ralat berlaku sesaat."
- Makluman yang ambangnya ialah nilai peratusan seperti "kekerapan 5xx ralat setiap 10% daripada jumlah volum permintaan pada masa tertentu."
- Makluman berdasarkan purata sejarah seperti "ralat 5xx pada persentil ke-90".
Secara umumnya, jenis 2 dan 3 lebih berguna untuk SRE yang bertugas, kerana ia mendedahkan penyelewengan daripada norma dalam proses.
2. Banyak amaran tidak pernah meningkat kepada insiden.
Jurutera SR berurusan dengan aliran makluman yang berterusan, kebanyakannya sebenarnya tidak kritikal.
Jadi mengapa tidak mengehadkan makluman anda kepada yang benar-benar penting sahaja? Dengan pendekatan ini, walau bagaimanapun, anda mungkin tidak mengenali gejala awal perkara yang akan menjadi masalah sebenar yang mengancam kerosakan besar.
Tugas SRE atas panggilan adalah untuk menentukan makluman yang sebenarnya menunjukkan sesuatu yang serius, dan sama ada ia perlu ditingkatkan dan ditangani. Saya mengesyaki ini juga disebabkan oleh ketidakfleksibelan makluman: adalah lebih baik jika terdapat beberapa tahap atau cara "pintar" untuk mengkonfigurasi makluman mengikut situasi yang diterangkan di atas.
Cadangan Ciri:
3. SRE kami yang bertugas menggunakan banyak alatan.
Dalaman:
- Projek infra GitLab: buku panduan hidup di sini, tugasan syif/minggu, tugas respons insiden.
- Isu GitLab: Siasatan, ulasan dan penyelenggaraan juga dijejaki dalam isu.
- Label GitLab: Tugasan automasi dilancarkan menggunakan label tertentu, yang bot gunakan untuk menjejak aktiviti tugas.
Luaran:
- PagerDuty: Makluman
- Slack: Aliran mesej PagerDuty/AlertManager pergi ke sini. Penyepaduan dengan arahan slash untuk melaksanakan pelbagai tugas, seperti menutup amaran atau meningkat kepada insiden.
- Grafana: visualisasi metrik dengan tumpuan pada arah aliran jangka panjang.
- Kibana: Memberi visualisasi/carian log, keupayaan untuk menggali lebih mendalam ke dalam peristiwa tertentu.
- Zum: Terdapat "bilik pelarian" yang sentiasa berjalan dalam Zum. Ini membolehkan jurutera SRE membincangkan acara dengan cepat tanpa membuang masa yang berharga untuk mencipta bilik dan menghubungkan peserta.
Dan banyak lagi yang lain.
4. Memantau GitLab.com dengan GitLab adalah satu titik kegagalan
Jika GitLab.com mengalami gangguan perkhidmatan yang besar, kami tidak mahu ia memberi kesan kepada keupayaan kami untuk menyelesaikan isu tersebut. Ia boleh dihentikan dengan melancarkan contoh GitLab kedua untuk mengurus GitLab.com. Malah, ini sudah berfungsi untuk kami: .
5. Beberapa ciri untuk dipertimbangkan untuk ditambahkan pada GitLab
- , serupa dengan Dokumen Google. Ini akan membantu dengan tugasan mengenai insiden semasa acara, serta tugasan untuk taklimat. Dalam kedua-dua kes, beberapa peserta mungkin perlu menambah sesuatu dalam masa nyata.
- Lebih banyak webhook untuk tugasan. Keupayaan untuk menjalankan langkah aliran kerja GitLab yang berbeza dari dalam akan membantu mengurangkan pergantungan anda pada integrasi Slack. Sebagai contoh, keupayaan untuk membenarkan makluman dalam PagerDuty melalui arahan slash dalam isu GitLab.
Kesimpulan
Jurutera SRE mempunyai masa yang sukar dengan banyak kerumitan. Alangkah baiknya untuk melihat lebih banyak produk GitLab yang menangani isu ini. Kami sedang mengusahakan beberapa penambahan pada produk yang akan memudahkan aliran kerja yang dinyatakan di atas. Butiran boleh didapati di .
Kami mengembangkan pasukan pada tahun 2020 untuk menggabungkan semua ciri hebat ini. Jika berminat, sila semak , dan jangan ragu untuk menghubungi sesiapa sahaja dalam pasukan kami dengan sebarang pertanyaan.
Sumber: www.habr.com