Cepat atau lambat, dalam proyek apa pun, saatnya untuk bekerja pada stabilitas / ketersediaan layanan Anda. Untuk beberapa layanan, pada tahap awal, kecepatan pengembangan fitur lebih penting, saat ini tim belum sepenuhnya terbentuk, dan teknologi tidak dipilih dengan sangat hati-hati. Untuk layanan lain (sering kali teknologi b2b), untuk mendapatkan kepercayaan pelanggan, kebutuhan akan waktu kerja tinggi muncul dengan rilis publik pertama. Tetapi anggaplah bahwa saat X bagaimanapun telah tiba dan Anda mulai peduli berapa banyak waktu layanan Anda "terletak" pada periode pelaporan. Di bawah potongan, saya sarankan untuk melihat apa yang dimaksud dengan waktu henti dan cara terbaik untuk menguranginya.
Indikator
Jelas, sebelum Anda memperbaiki sesuatu, Anda perlu memahami keadaan saat ini. Oleh karena itu, jika kita mulai mengurangi waktu henti, itu yang pertama-tama dan perlu untuk mulai mengukurnya.
Kami tidak akan berbicara di sini secara rinci tentang bagaimana melakukan hal ini secara khusus, pro dan kontra dari berbagai pendekatan, tetapi proses tesisnya terlihat seperti ini:
- kami mengandalkan metrik bisnis dekat (kesalahan dalam layanan, waktu respons layanan, $ / detik, pendaftaran / detik, dll.)
- tentukan apa yang baik dan apa yang buruk
- transisi baik-> buruk adalah awal dari suatu insiden
- transisi buruk-> baik - akhir dari insiden
- waktu dari awal hingga akhir - durasi kejadian (tutup bersama kami)
- jumlah durasi insiden untuk periode (bulan / kuartal / tahun) - downtime
- (100 - <downtime> / <durasi periode> * 100) = persentase ketersediaan untuk periode tersebut
Ketika berbicara tentang uptime / downtime, mereka sering menyebutkan indikator lain:
MTTR (waktu rata-rata untuk memperbaiki) - waktu rata-rata dari awal insiden hingga akhir.
Masalah dengannya mulai dari kata pertama dalam singkatan. Mengingat bahwa semua insiden berbeda, rata-rata durasinya tidak dapat memberi tahu kami apa pun tentang sistem.
Kali ini kami tidak akan rata-rata apa pun, tetapi hanya melihat apa yang terjadi selama kejadian.
Anatomi suatu kejadian
Mari kita lihat langkah penting apa yang dapat dibedakan selama kejadian:
- deteksi - interval antara kesalahan pertama yang kami berikan kepada pengguna sebelum petugas menerima SMS
- reaksi - dari menerima pemberitahuan tentang masalah hingga saat seseorang mulai menyelesaikan masalah ini (biasanya pada saat itu acara pemantauan dipindahkan ke keadaan yang Diakui)
- investigasi - dari awal pekerjaan pada masalah hingga saat penyebab insiden dipahami dan kami tahu apa yang perlu dilakukan untuk memulihkan pekerjaan.
- eliminasi - waktu pemulihan, misalnya, rilis rollback, dipromosikan baru
tuan server basis data primer
Mungkin model kami tidak lengkap dan ada beberapa tahap lain, tetapi saya mengusulkan untuk memperkenalkan mereka hanya setelah menyadari bagaimana ini akan membantu kami dalam praktik. Sementara itu, pertimbangkan lebih detail setiap tahap.
Deteksi
Mengapa kita menghabiskan waktu mencari keadaan darurat? Mengapa tidak mengirim pemberitahuan tentang kesalahan pertama yang diterima pengguna? Sebenarnya, saya tahu banyak perusahaan yang mencoba melakukan ini, tetapi mereka meninggalkan ide ini hanya beberapa jam kemudian, dan mereka menerima beberapa puluh SMS. Saya pikir tidak ada satu pun layanan yang kurang lebih besar yang tidak memiliki aliran kesalahan "latar belakang" yang konstan. Tidak semua dari mereka adalah tanda bahwa ada sesuatu yang rusak, ada juga bug dalam perangkat lunak, data tidak valid yang diperoleh dari formulir dan tidak cukup validasi, dll.
Akibatnya, tingkat kesalahan (atau metrik lainnya) yang melebihi fluktuasi harian digunakan sebagai kriteria untuk membuka insiden. Inilah yang mengarah pada fakta bahwa pemberitahuan karyawan yang bertanggung jawab terjadi lebih lambat dari permulaan masalah sebenarnya.
Tetapi kembali ke tugas awal kita - mengurangi durasi insiden. Bagaimana kita dapat mempersingkat waktu deteksi? Lebih cepat memberi tahu? Datang dengan logika super untuk mendeteksi anomali?
Saya sarankan belum melakukan apa-apa, tetapi untuk melihat tahap selanjutnya, karena pada kenyataannya mereka saling berhubungan.
Reaksi
Di sini kita memiliki faktor manusia murni. Kami berasumsi bahwa pemantauan berhasil mendeteksi masalah dan kami berhasil membangunkan insinyur yang bertugas (seluruh eskalasi juga bekerja pada tahap sebelumnya).
Pertimbangkan kasus "terburuk", kami tidak memiliki layanan tugas khusus, dan lansiran menangkap admin yang tidur dengan damai. Tindakannya:
- menanggapi SMS: di sini seorang istri dengan telinga yang sensitif banyak membantu, berbagai aplikasi untuk telepon, meningkatkan efek menerima SMS (1-5 menit)
- membuat keputusan bahwa ia akan merangkak keluar dari tempat tidur: jika peringatan tidak diatur dengan benar, seseorang dapat menunggu 2 menit "bagaimana jika tekad datang?" dan tertidur (1-15 menit)
- pergi ke laptop, buka mata Anda, bangun, mulai pemantauan, tekan Ack: (1-15 menit)
Akibatnya, dalam kasus terburuk, kami mendapat 35 menit reaksi. Menurut pengamatan saya, waktu reaksi seperti itu tampaknya benar.
Karena pada tahap ini kita berurusan dengan orang, kita harus bertindak sangat hati-hati dan penuh pertimbangan. Dalam hal apa pun, Anda tidak perlu menulis peraturan yang mengharuskan seseorang yang baru bangun tidur harus pindah! Mari kita ciptakan kondisinya.
Mari singkirkan keraguan sang insinyur bahwa masalahnya akan berakhir dengan sendirinya. Ini dilakukan dengan sangat sederhana: buat kriteria waspada tidak sensitif terhadap masalah kecil dan beri tahu jika insiden itu berlangsung dalam waktu yang signifikan . Ya, kami baru saja meningkatkan durasi tahap "deteksi", tetapi mari kita lihat sebuah contoh:
- menambah waktu deteksi 5 menit
- jumlah insiden berkurang: semua kesalahan singkat biasanya jatuh dalam 1 menit. Insiden singkat ini harus dicatat, tetapi tanpa memberi tahu orang. Seringkali, mereka memberikan total downtime yang sangat besar, tetapi Anda dapat mengatasinya selama jam kerja. Untuk tugas ini, Anda akan memerlukan granularity tinggi dalam pemantauan, karena masalahnya sudah berakhir, dan alat diagnostik untuk sebagian besar tidak menyimpan sejarah.
- jika seseorang dipaksa untuk merespons peringatan sebulan sekali atau kurang sering, dan tidak setiap hari, dia akan merespons dengan lebih memadai dan tidak memperlakukan ini sebagai rutin
- pemberitahuan yang tertunda memungkinkan seseorang untuk tidak berpikir: jika SMS datang, maka semuanya serius dan tidak akan diperbaiki sendiri
Berpotensi, pendekatan ini akan mengurangi total waktu reaksi hingga 15+ menit. Jika waktu reaksi seperti itu tidak sesuai dengan Anda, Anda harus memikirkan layanan tugas.
Investigasi
Mungkin ini adalah tahap kecelakaan yang paling sulit ketika Anda perlu memahami apa yang terjadi dan apa yang harus dilakukan. Pada kenyataannya, tahap ini sangat sering dikombinasikan dengan tahap pengambilan tindakan, karena biasanya prosesnya seperti ini:
- kami melihat pemantauan, log (jika pemantauan tidak cukup), kami meluncurkan beberapa alat diagnostik lainnya
- mengajukan hipotesis
- kami menguji hipotesis, baik dengan metrik, atau dengan melakukan beberapa tindakan (restart semuanya :)
- mengevaluasi hasil perubahan
- berkomunikasi dengan kolega jika pengetahuan Anda tentang subsistem tertentu tidak cukup
dan seterusnya sampai pencerahan atau akhir dari kejadian.
Tahap ini biasanya yang paling signifikan dalam total durasi kejadian. Bagaimana cara menguranginya?
Semuanya tidak begitu jelas di sini, ada beberapa vektor:
- Sederhanakan infrastruktur Anda : Bayangkan seberapa cepat orang yang memiliki satu basis data dan satu layanan macet
- penyebaran pengetahuan dalam tim : ideal jika komunikasi orang tidak berjalan selama kejadian, tetapi selama pekerjaan sehari-hari (komunikasi orang biasanya merupakan proses yang sangat panjang)
- pemantauan : banyak orang berpikir bahwa pemantauan hanya berfungsi pada tahap "deteksi", tetapi sebenarnya pemantauan dapat bertindak sebagai optimisasi proses pengujian hipotesis ("apakah basis data berfungsi dengan baik?", "apakah layanan saya berjalan ke sumber daya?") dan juga sebagai transportasi penyebaran pengetahuan dalam sebuah tim. "Serge, periksa apakah ada kesalahan dalam log X tentang deadlock?" dapat diubah menjadi pemicu, deskripsi yang akan menjadi tautan ke wiki dengan instruksi .
Eliminasi
Seperti yang saya katakan di atas, tahap ini sering menyatu dengan yang sebelumnya. Tetapi kebetulan alasannya segera jelas, tetapi pemulihan akan sangat lama. Misalnya, Anda memiliki server yang mati tuan primer (saya tidak akan terbiasa dengannya sejak lama :) dengan database, dan Anda tidak pernah mempromosikan replika, yaitu, Anda akan membaca dokumentasi, meluncurkan konfigurasi aplikasi baru, dll.
Secara alami, setelah setiap insiden penting, Anda perlu mencari tahu bagaimana mencegah hal ini terjadi lagi atau mempercepat pemulihan. Tapi mari kita lihat arah apa yang bisa kita coba secara proaktif:
- alat manajemen infrastruktur : jika untuk memperbaiki semua yang Anda butuhkan untuk meluncurkan konfigurasi baru, tetapi ini dilakukan setidaknya dalam 20 menit - ini adalah keterbatasan Anda. Cobalah untuk membuat skenario tentang apa yang mungkin terjadi dan cara untuk mempercepat beberapa proses. Misalnya, jika Anda telah menetapkan serial (pelaksanaan tugas paralel) = 3, tetapi jika Anda masih berbohong, Anda dapat menggunakan serial = 30, Anda perlu mengajari semua orang untuk mendefinisikan ulang ini (mirip dengan strategi pembaruan bergulir di kubernetes).
- latihan : jika Anda tahu kemungkinan skenario kegagalan dan pemulihan tidak otomatis, Anda harus memiliki instruksi yang harus diuji . Rencanakan waktu istirahat (jika perlu), lakukan latihan. Seringkali, pada tahap ini, kasus-kasus seperti itu terotomatisasi, karena sebagian besar jebakan bahkan prosedur paling rumit pada pandangan pertama diklarifikasi selama latihan.
- interaksi dengan kontraktor : Anda harus tahu sebelumnya apa yang akan Anda lakukan jika penyedia hosting Anda sakit. Seringkali, kesadaran akan kemungkinan masalah dan biaya penutupan risiko mengarah pada kesimpulan - "kita hanya akan menunggu pemulihan." Tetapi di sisi lain, insinyur dan bisnis akan siap untuk skenario seperti itu. Misalnya, Anda dapat mengatasi masalah pengalihan lalu lintas ke tulisan rintisan yang sudah disiapkan, memberi tahu pengguna dengan surat yang disiapkan sebelumnya, dll. Atau sebaliknya, Anda membuat instruksi yang menurutnya kami memberi hoster 30 menit untuk pulih, dan kemudian kami mulai pindah ke DC lain, di mana sudah ada replika database, tetapi Anda perlu memperluas yang lainnya. Dan di sini sekali lagi, ajarannya, kami mencatat waktu untuk bergerak, dll.
MTBF (Mean Time Between Failures)
Metrik umum lain yang disebutkan dalam diskusi uptime. Sekali lagi, saya mengusulkan untuk tidak rata-rata apa pun, tetapi hanya untuk berbicara tentang jumlah insiden yang terjadi selama interval waktu.
Inilah pertanyaan utama tentang seberapa banyak Anda telah menjaga toleransi kesalahan layanan Anda:
- Adakah titik kegagalan tunggal (SPOF) dalam infrastruktur, berapa probabilitas kegagalan?
- Seberapa yakin Anda bahwa tidak ada SPOF yang tidak Anda ketahui? (Inilah masalah yang dipecahkan oleh kekacauan monyet )
- Apakah load balancers berfungsi dengan baik? ( laporan saya tentang keseimbangan )
- seberapa tangguh jaringan?
- Seberapa andalkah pusat data?
Terkadang, untuk menghitung / memprediksi semua ini, mereka membuat "peta risiko", di mana setiap skenario (yang bisa diasumsikan, tentu saja selalu ada yang belum kita ketahui) memiliki probabilitas + dampak (downtime pendek / panjang, kehilangan data, kehilangan reputasi , dll.). Kemudian, mereka secara sistematis bekerja pada kartu semacam itu, pertama-tama menutup semua skenario yang sangat mungkin dan serius dalam hal dampak.
Teknik lain yang dapat digunakan adalah klasifikasi insiden masa lalu. Ada banyak pembicaraan sekarang bahwa sangat berguna untuk menulis insiden "post mortem", yang menganalisis penyebab masalah, tindakan orang, mencari kemungkinan tindakan di masa depan. Tetapi untuk melihat dengan cepat penyebab semua kecelakaan selama periode yang lalu, akan lebih mudah untuk meringkas durasi mereka dengan pengelompokan berdasarkan “kelas masalah” dan di mana waktu paling henti adalah mengambil tindakan:
- kesalahan manusia : mengurangi jumlah tindakan manual dalam produksi, berbagai perlindungan terhadap kesalahan operator
- rilis yang tidak berhasil : ada baiknya meningkatkan pengujian (termasuk pengujian beban)
- kesalahan aplikasi : memperbaiki kebocoran, kerusakan dan pembekuan lainnya
- jaringan : membeli peralatan, mengatur, merekrut penggiat jejaring, mengganti kontraktor
- Database : pekerjakan DBA, rawat toleransi kesalahan, beli perangkat keras yang lebih baik
- DC : pikirkan cadangan atau relokasi
- pengaruh eksternal (ddos, pemblokiran, ulasan sertifikat, domain): membeli antiddo, persediaan pada proxy, memantau masa berlaku domain / sertifikat, memiliki beberapa sertifikat dari CA yang berbeda.
Artinya, jika Anda bahkan tidak mencoba memprediksi kemungkinan skenario masalah, maka sudah pasti layak bekerja dengan insiden yang sudah terjadi.
Total
Semua insiden berbeda:
Algoritma untuk bekerja untuk meningkatkan uptime sangat mirip dengan optimasi lainnya:
-> -> ->
Dari pengalaman saya sendiri, saya dapat mengatakan bahwa untuk peningkatan waktu aktif yang signifikan, cukup dengan mulai mengikutinya dan menganalisis penyebab insiden. Biasanya terjadi bahwa perubahan paling sederhana membawa efek paling signifikan.
Layanan pemantauan kami membantu tidak hanya dengan tahap "deteksi", tetapi juga sangat mengurangi "penyelidikan" (pelanggan akan mengonfirmasi)