Sebelum menjawab pertanyaan "Bagaimana mengukur kesuksesan?", Anda perlu memahami apa arti "kesuksesan" bagi Anda. Bagi Dev dan Ops, definisi kesuksesan berbeda. Bagi Dev, proyek yang sukses sepenuhnya diuji. Untuk operasi - pemantauan. Diperlukan pengujian dan pemantauan, tetapi pengujian tidak pernah memberikan cakupan masalah 100%, dan respons 200 dari HTTP tidak cukup untuk memastikan sistem bekerja dengan baik. Leon Fayer di RIT ++ membela sudut pandang bahwa DevOps tidak membayar untuk memastikan bahwa semua metrik dalam pemantauan berada di zona hijau. Mereka membayar untuk membuat pengguna senang . Jika Anda tidak puas - bisnis kehilangan uang, dan tidak ada yang peduli bahwa semuanya hijau.
Di bawah kucing ada banyak contoh dari praktik yang membuktikan sudut pandang ini. Mari kita cari tahu mengapa memahami bisnis, cara memantau kesuksesan dari sudut pandang bisnis, dan mengapa pengembang biasa membutuhkannya.
Tentang pembicara: Leon Fayer lahir di republik yang tadinya bersahabat, tetapi dibesarkan di Amerika Serikat. Saya mulai pemrograman bertahun-tahun yang lalu, dan selama waktu itu saya bekerja sebagai programmer, manajer, yang saya tidak bekerja. Berpartisipasi dalam startup - beberapa lebih sukses, dan beberapa tidak terlalu sukses.
Selama bertahun-tahun, Leon telah bekerja di OmniTI. Perusahaan ini berspesialisasi dalam mengembangkan sistem yang skalabel, sehingga Leon memiliki peluang unik untuk merancang dan membangun sistem untuk situs yang paling banyak dikunjungi di dunia - Wikipedia, National Geographic, Gedung Putih, MTV, dll.
Sebelum menjawab pertanyaan "Bagaimana mengukur kesuksesan?", Anda perlu memahami apa arti "kesuksesan" bagi Anda. Untuk setiap orang, jawabannya akan berbeda.
Jika Anda membaca artikel ini, kemungkinan besar Anda terlibat dengan DevOps. Apakah Anda Lebih Dev Daripada Ops? Atau, sebaliknya, lebih banyak Ops daripada Dev? Untuk Dev dan Ops, definisi kesuksesan agak berbeda: untuk Dev, tentu saja, adalah pengujian.
Pengujian
Bagi saya, sebagai seorang programmer, pengujian yang sukses berarti bahwa semuanya sudah beres, semuanya baik-baik saja, semuanya berfungsi - Anda dapat menjalankannya dalam produksi. Masalahnya adalah bahwa saya juga seorang yang sinis, dan bukan penggemar pengujian seperti itu. Bukan karena itu sulit, dan bukan karena itu panjang - tetapi karena pengujian tidak memberikan apa yang saya inginkan.
Memahami saya dengan benar, pengujian adalah proses wajib , harus dimasukkan dalam proyek apa pun, tetapi jelas tidak cukup untuk menjamin kesuksesan .
Ada banyak opsi pengujian yang berbeda:
- tes kinerja;
- tes pengguna;
- pengujian otomatis ...
Berapa banyak metode pengujian yang Anda gunakan - 1, 2, 3, 5? Dan apa, Anda tidak terjaga di malam hari waspada? Apakah semuanya berfungsi dalam produksi?
Masalahnya adalah pengujian memberi ilusi kesuksesan . Sudah ditentukan sebelumnya: kita tahu bahwa kereta harus meninggalkan titik A dan mencapai titik B, untuk ini kami sedang menguji. Ada beberapa opsi yang kami pertimbangkan. Jika kereta jatuh dari roda atau kehabisan kayu, ini tidak akan mengejutkan. Tapi kami tidak menguji, misalnya, melatih perampokan. Kami tidak dapat menguji ini karena kami tidak tahu bahwa opsi seperti itu mungkin.
Ada beberapa masalah karena pengujian tidak cukup. Yang pertama, tentu saja, adalah masalah data . Fakta bahwa tugas tersebut bekerja secara lokal, tetapi karena alasan tertentu tidak bekerja dalam produksi, merupakan masalah standar.
Tidak peduli seberapa keras kita berusaha. Tidak masalah berapa banyak replikasi yang kita jalani - pengembangan dan produksi tidak akan pernah sama. Apakah akan ada baris lain dalam basis data, apakah akan ada permintaan tambahan lain - akan selalu ada sesuatu dalam produksi yang tidak kami harapkan.
Wolfe + 585 - nama belakang terpanjang di dunia:
Hubert blaine
Wolfeschlegelsteinhausenbergerdorffwelchevoralternwaren-gewissenhaftschaferswessenschafewarenwohlgepflegeundsorgfaltigkeitbeschutzen-vorangreifendurchihrraubgierigfeindewelchevoralternzwolfhunderttausendjahres-vorandieerscheinenvonderersteerdemenschderraumschiffgenachtmittungsteinund- siebeniridiumelektrischmotorsgebrauchlichtalsseinursprungvonkraftgestartsein-langefahrthinzwischensternartigraumaufdersuchennachbarschaftdersternwelchege-habtbewohnbarplanetenkreisedrehensichundwohinderneuerassevonverstandig-menschlichkeitkonntefortpflanzenundsicherfreuenanlebenslanglichfreudeundruhe-mitnichteinfurchtvorangreifenvorandererintelligentgeschopfsvonhinzwischensternartigraum,
Sr.
Beberapa sistem akan bertahan jika seseorang memasukkan nama belakang seperti itu pada formulir. Saya tahu setidaknya 5 titik berbeda di mana seluruh sistem bisa terbang.
Oleh karena itu, masalah kedua adalah masalah dengan pengguna .
Mereka adalah orang-orang yang menarik yang akan merusak apa pun. Jika tidak ada pengguna, semuanya akan lebih mudah, jujur.
Bahkan jika ada satu tombol di UI Anda, mereka masih akan menemukan metode untuk melanggar apa yang kami lakukan.
Contoh terbaik adalah World of Warcraft .
Bagi mereka yang tidak tahu, ini adalah game online yang dimainkan oleh 10 juta orang. Pada suatu waktu ada bug yang cukup legendaris. Bug darah yang terkorupsi adalah contoh sempurna tentang bagaimana pengguna merusak segalanya.
Seperti halnya mainan, di World of Warcraft konten baru, ide-ide baru, bos baru terus muncul. Salah satu bos baru mengutuk salah satu dari 40 pemain dalam grup. Prinsip kutukan itu seperti bom waktu - perlahan-lahan merenggut nyawa semua orang di sekitarnya. Artinya, perlu melarikan diri ke samping - ada seluruh mekanik. Dan semuanya baik-baik saja sampai, pada titik tertentu, salah satu pemain memutuskan untuk berteleportasi ke kota selama pertempuran ...
Di kota itu ada ribuan orang dari semua tingkatan, yang terkecil juga. Tidak hanya itu, masih ada karakter non-pemain yang juga terinfeksi kutukan. Pada siang hari, server kosong. Mustahil untuk pergi ke mana pun, di mana ada pemain lain. Itu menjadi wabah game dalam arti sebenarnya dari kata itu. Saya harus melakukan restart semua server untuk menghapus kutukan dan mengubah mekanik. Dan semuanya karena satu tester - Saya bahkan tidak tahu harus menyebutnya apa.
Masalah utama ketiga adalah masalah dengan ketergantungan eksternal . Kita semua menemukan ini: API tempat Anda bergantung tiba-tiba berhenti berfungsi; atau Anda berhenti mengendalikan API.
Tetapi ada masalah yang lebih besar dengan ini. Ketergantungan eksternal tidak hanya bisa langsung, tetapi juga tidak langsung. Kita semua menggunakan OpenSource sekarang. Setiap produk OpenSource tergantung pada beberapa pustaka, yang juga OpenSource dan yang didukung oleh orang lain. Ketika sesuatu rusak, itu rusak tidak hanya dalam modul kecil ini, tetapi dalam segala hal yang bergantung padanya.
Mungkin contoh yang paling ideal adalah baru-baru ini, sekitar setahun yang lalu - ini adalah pad kiri . Ini adalah modul npm pada node.js yang memperlihatkan spasi sebelum string (di awal baris). Kami tidak akan membahas mengapa modul ini dibuat. Tetapi ternyata itu termasuk dalam banyak modul populer. Pada titik tertentu, penulis memutuskan bahwa ia sudah cukup, menghapus modul ini dari npm, dan 70% dari kode yang ditulis dalam node.js terbang.
Jika Anda berpikir bahwa ini adalah kasus yang terisolasi, Anda salah.
Ada juga modul is-odd, yang sekarang dalam npm. Modul ini menentukan angka genap atau tidak.
Kami tidak akan membahas fakta bahwa 3 juta orang tidak tahu cara memeriksa paritas / keanehan. Tetapi ada 12 modul lagi yang menggunakannya! Dan tidak diketahui berapa banyak modul ini masih menggunakan modul. Jika Anda merasa tidak ada yang bisa dibobol - ada 5 versi!
Kembali ke domba kita - ada banyak pilihan:
- Pandangan picik - kita tidak tahu apa yang akan terjadi di masa depan. Y2K adalah contoh sempurna. Tidak ada yang hanya berpikir bahwa pada tahun 2000 semua yang ditulis dalam Kobol akan terbang.
- Jumlah opsi pengujian .
Ada contoh yang baik lagi dengan World of Warcraft - mereka memiliki banyak contoh bagus tentang hal ini.
Enam bulan setelah perilisan game, seruan mulai datang untuk mendukung bahwa beberapa pemain tidak bisa memasuki satu gua. Ternyata hanya satu versi ras dan jenis kelamin tidak bisa memasuki gua ini - ini adalah tauren perempuan.
Mengapa butuh 6 bulan untuk menemukan kesalahan ini - lagipula, jutaan orang bermain? Karena tauren adalah ras fiksi, campuran manusia dan banteng. Wanita Tauren adalah sapi yang bisa bicara. Tidak ada yang mau bermain sapi, jadi selama 6 bulan tidak ada satu orang yang mencapai tingkat maksimum untuk pergi ke gua dan menemukan bug ini. Dengan demikian, tidak ada yang mengujinya.
- Ubah data sumber. Kami benar-benar tidak tahu apa yang akan terjadi besok.
Bagaimanapun, ada beberapa tes. Tetapi tes tidak memberikan cakupan 100%. Karena itu, pengujian tidak menjamin kesuksesan. Ini secara bertahap membawa kita ke bagian kedua - Ops. Untuk eksploitasi, kesuksesan adalah pemantauan .
Pemantauan
Ada banyak alasan mengapa pemantauan diperlukan:
- kode sempurna tidak ada;
- sistem menjadi lebih kompleks;
- meningkatnya ketergantungan eksternal;
- antisipasi -> respons;
- ...
Pemantauan diperlukan karena semuanya berubah. Inilah alasan utamanya. Selain itu, ini dalam produksi, semuanya berubah secara konstan di sana, dan kita perlu mendeteksi ini.
Apa yang harus memantau cakupan? - Itu dia! Ini adalah jawaban singkat, tetapi harus mencakup semuanya.
Ini semua agak abstrak. Faktanya, kita semua memiliki daftar periksa yang kita pantau:
- infrastruktur
- Basis data
- Aplikasi
- titik integrasi;
- meminta waktu pemrosesan;
- memuat;
- ...
Mungkin ada sejuta hal. Banyak yang mengumpulkan ratusan, ribuan, dan puluhan ribu metrik pada sistem mereka.
Kami akan mengumpulkan banyak metrik untuk ini:
Tentu saja, saya melebih-lebihkan, tetapi yang kita butuhkan dari sudut pandang Ops adalah agar HTTP mengembalikan 200 . Ini berarti semuanya baik-baik saja dengan situs. Setelah sebuah situs berfungsi, itu berarti bahwa basis data berfungsi, aplikasi berfungsi - semuanya teratur. Dari sudut pandang Ops, sukses adalah persis seperti itu: semua grafik ada di zona hijau, semuanya bekerja dengan benar - semuanya baik-baik saja!
Semua orang tahu apa itu Twitter. Mereka memproses 500 juta tweet per hari - jumlah yang gila.
Tetapi mereka juga dikenal karena kesalahan mereka. Kesalahan legendaris dalam kompleksitas atau kemudahannya - sisi mana yang harus dilihat.
Mereka memiliki kesalahan: situs itu berfungsi, klien dapat menulis tweet, mengklik tombol, mereka mengucapkan terima kasih, tweet itu dikirim - dan hanya itu! Dia tidak muncul di mana pun dan menghilang begitu saja, dan pemantauan menunjukkan bahwa semuanya beres. Situs mengembalikan 200 permintaan - API berfungsi. Tapi tidak ada tweet!
Saya punya kutipan favorit dari satu pelanggan. Saya memperbaiki masalah pada tiga layar selama satu jam, dan dia berteriak mengapa tidak ada yang berhasil. Ketika saya mencoba menjelaskan masalah apa yang saya perbaiki, seseorang yang mengetik dengan dua jari dan tidak mengerti cara menggunakan komputer memberi tahu saya:
"Selama saya terus menghasilkan uang, bagi saya server-server itu aktif."
Dalam beberapa hal, ini sangat benar, dan contoh Twitter mengonfirmasi hal ini: semua metrik menunjukkan bahwa segala sesuatunya sesuai dari sudut pandang pengembang, tetapi dari sudut pandang pekerjaan bisnis, itu sama sekali tidak berurutan.
Sejujurnya, kita semua harus disalahkan. Tentu saja, perusahaan-perusahaan yang memproduksi produk pemantauan terutama yang harus disalahkan. Tapi kami juga, karena secara tradisional kami mengumpulkan metrik sistem. Kami terbiasa bekerja dengan sistem kecil - satu, mungkin dua server. Jika mereka bekerja, maka semuanya beres.
Sekarang kita memiliki lebih banyak server daripada dua, atau bahkan 10, dan hanya mengukur kesehatan sistem atau kesehatan program tidak cukup. Kita harus melacak pekerjaan dari hal lain.
Kembali ke kutipan, saya dibayar tidak untuk semuanya menjadi hijau. Saya dibayar sehingga pengguna atau manajer saya puas - seseorang harus senang dengan hasilnya . Jika semua pengguna tidak bahagia, tidak ada yang peduli bahwa semuanya berwarna hijau.
Pengawasan bisnis
Kami mengatakan bahwa pemantauan diperlukan karena semuanya berubah. Tetapi ketika semuanya berubah, perubahan mempengaruhi bisnis: sesuatu telah rusak - uang telah berhenti masuk, sesuatu telah diperbaiki - uang sudah mulai mengalir lagi - korelasi langsung. Atau mereka tidak mempengaruhi - tetapi jika kita tidak memantau bisnis, kita tidak tahu itu.
Sebagai contoh nyata, grafik pembacaan cache sudah dikenal semua orang.
90% dari waktu, semuanya beres, hampir semua permintaan masuk ke cache. Dan tiba-tiba sesuatu terjadi - dan sangat serius. Ini adalah masalah yang harus bangun jam 3 pagi seseorang yang akan menyelesaikannya. Tetapi, jika kecepatan unduh untuk pengguna tidak berubah, apakah ini benar-benar masalah?
Dalam bahasa Inggris ada istilah Observability - observability. Ini adalah: pemantauan, penebangan, peringatan. Oleh karena itu, istilah pemantauannya sedikit. Kami ingin mengamati semuanya - kumpulkan metrik sistem pada setiap node, jika perlu. Tetapi kami ingin memantau bisnis, karena ini menggairahkan semua orang. Ini merupakan indikator keberhasilan.
Untuk melakukan ini, kita harus:
1. Memahami masalah - apa sebenarnya yang perlu kita pantau.
2. Tentukan garis dasar - yaitu, apakah cukup bahwa kecepatan unduh pengguna tidak berubah sehingga tidak ada yang terbangun di tengah malam ketika membaca dari cache telah berhenti bekerja.
3. Data yang berhubungan adalah salah satu faktor terpenting. Jika pemasaran mengumpulkan data tentang pendapatan, dan Anda mengumpulkan data di server dan tidak dapat membandingkan kedua pengamatan ini, maka mereka memiliki sedikit makna.
Saya biasanya memberi banyak contoh. Tidak peduli seberapa absurd mereka akan terlihat, mereka semua dari hidupku, dan aku menghabiskan banyak keberanian pada mereka.
Contoh: Saya punya klien dengan 100 juta pengguna. Itu adalah perusahaan pemasaran internet yang mengirim banyak email dan menggunakan pengujian A / B. Untuk mereka, kami mengumpulkan 6 ribu metrik.
Segalanya, seperti biasa, dimulai dengan sebuah panggilan. Telepon berdering - itu berarti sesuatu terjadi.
" Kami punya masalah." Sesuatu tidak berfungsi.
- Oke, apa yang sebenarnya tidak berhasil? Apa ini diungkapkan?
- Kami mulai menerima lebih sedikit penghasilan.
- Dan?
- Sesuatu tidak bekerja di sistem.
- Saya tidak mengerti. Jika penghasilan lebih sedikit, bicarakan dengan tim penjualan Anda. Kenapa kau memanggilku?
- Tidak, saya yakin sesuatu dalam sistem tidak berfungsi!
- Baiklah, mari kita lihat.
Alhamdulillah kami memiliki metrik pendapatan, sehingga kami bisa melihat. Grafik tersebut benar-benar menunjukkan bahwa pada titik tertentu penghasilan mereka turun 15%. Mengingat jumlah pengguna, ini cukup signifikan.
Oke, saya harus melihat. Pertama-tama, saya memeriksa kecepatan unduh - normal.
Kami melihat beban pada database - semuanya dalam batas wajar, tampaknya tidak ada yang berubah. Kemudian kami mulai melihat beban cpu, pada masing-masing node, pada cache.
Semuanya beres. Hingga kami sampai ke metrik buletin email. Salah satu penyedia besar secara tidak sengaja memasukkan domain mereka ke daftar hitam. Persentase pemasaran email mereka telah berhenti menjangkau pengguna, yang berarti lebih sedikit orang: menerima surat, mengklik tombol, pergi ke situs dan membeli sesuatu.
Inilah korelasi seperti itu!
Kami beruntung memiliki metrik ini. Jika kami tidak memilikinya, kami akan menambahkannya - ini adalah jawaban yang sangat sederhana.
Kesalahan terbesar yang dilakukan orang adalah percaya bahwa pemantauan dapat dilakukan di akhir proyek. Ini seperti fitur: untuk membuat proyek Anda sendiri, melakukan pemantauan - dan itu saja, kami siap!
Instrumentasi tidak pernah bisa selesai. Selalu ada masalah yang tidak diketahui sejak awal. Seperti halnya pengujian, Anda tidak dapat menulis tes dan mencakup semuanya, karena Anda tidak tahu apa itu "segalanya". Kami tidak tahu bagaimana memprediksi masa depan dan kami tidak tahu bagaimana memprediksi bisnis, jadi kami tidak tahu apa "segalanya" itu.
Contoh yang sangat identik dengan apa yang saya bicarakan. Adalah CEO, yang bangun di sebuah konferensi di Paris di pagi hari, minum kopi, melihat surat dan laporan pendapatannya, dan memanggil saya dengan masalah yang sama: pendapatan turun.
Saya mengingatnya dengan baik, karena dia punya jam 9 pagi, dan saya punya 6 jam sebelumnya, juga pada hari Sabtu. Saya baru saja diangkut pulang dari pesta ulang tahun - tetapi itu tidak masalah. Jadi, jam 3 pagi saya duduk di depan komputer, dan kita mulai melakukan langkah yang sama. Yaitu, kita melihat beban pada sistem, pada nomor registrasi, sama sekali.
Satu-satunya penyimpangan dari norma yang kami temukan adalah persentase yang lebih rendah dari otorisasi yang berhasil. Artinya, jumlahnya sama, tetapi persentasenya sedikit lebih rendah. Saya tahu ini bisa jadi spam, dll. Tetapi semua metrik teknis lainnya benar-benar normal. Dan kami sampai pada titik di mana kami hampir berjalan di sepanjang garis dalam basis data dan mencoba memeriksa apakah ada sesuatu yang bisa ditangkap dengan mata. Sama sekali tidak ada!
Kami duduk setengah Minggu, terus pada hari Senin, tetapi sudah yakin bahwa masalahnya bukan teknis. Biarkan mereka yang memutuskan sendiri. Dan di sini pada hari Senin saya duduk di tempat kerja dan seorang karyawan dari departemen akuntansi memanggil saya:
- Dengar, bisakah kamu membantuku dengan cepat?
- Apa yang kamu butuhkan?
- Bisakah Anda menghapus lencana American Express dari situs?
- Tentu saya bisa! Kenapa tiba-tiba?
- Anda tahu, kami berdebat dengan mereka di sini, dan sampai kami menerima orang Amerika
Ekspresikan secara umum.
"Aku minta maaf untuk bertanya, kapan kamu berhenti mengambilnya?"
- Sebelum akhir pekan, menurut pendapat saya - pada hari Jumat atau Sabtu .
Tidak ada orang yang waras yang akan menagih metrik pada persentase otorisasi dari jenis kartu kredit tertentu! Setelah kejadian ini, tentu saja, kami atur.
Kenapa aku memberitahumu ini? Pertama-tama Anda harus melihat bisnisnya, karena semua masalah sistemik ini tidak terlihat. Mereka tidak membangunkan siapa pun di tengah malam, kami tidak melihat bahwa ini adalah masalah. Sangat mudah untuk melihat penurunan pendapatan, dan segala hal lainnya perlu dilacak sehingga Anda dapat menghubungkan data ini dengan data bisnis.
Sukses untuk bisnis
Untuk bisnis, kesuksesan dapat berbeda, tergantung pada tujuan. Yang paling penting, bagaimana ini bisa diukur? Secara tradisional, kami mengukur kinerja sistem, terkadang sebagai insinyur, lupa bahwa Anda dapat mengukur apa pun.
Misalnya, Anda dapat mengukur alkoholisme Anda sendiri. Ngomong-ngomong, aku tidak bercanda. Di kantor kami ada bir dengan empat ketukan. Karena kita semua insinyur, rekan saya memutuskan untuk memakai sensor Raspberry Pi untuk melihat berapa banyak bir yang kita minum dan yang mana.
Itu terlihat seperti lelucon sederhana, tetapi sebenarnya itu nyaman, karena kita melihat kapan bir berakhir dan kita perlu mengganti tong. Secara umum, kita bisa melihat ketika orang minum, bir mana yang paling mereka sukai - gelap, terang, dll. Ngomong-ngomong, puncaknya adalah hari ulang tahunku.
Benar-benar kebetulan, kami menemukan aplikasi lain untuk ini.
Grafik menunjukkan konsumsi bir selama beberapa hari dan akhir pekan. Pada akhir pekan, konsumsi alkohol biasanya menurun, hampir menghilang. Suatu hari kami tiba pada hari Senin, lihat jadwal dan melihat seseorang pada hari Sabtu minum seperempat barel bir. Grafik menunjukkan waktu yang tepat dalam setengah jam. Ternyata petugas kebersihan yang datang pada hari Sabtu harus mabuk, jadi mereka mabuk.
Lelucon, tetapi pada akhirnya mereka memiliki masalah serius, karena biasanya buruk untuk minum di tempat kerja, dan bahkan bir orang lain!
Pada akhirnya, metrik apa pun bisa bermanfaat. Bahkan metrik ini, yang kami kumpulkan hanya untuk penggemar kami sendiri, ternyata menjadi penting dalam hal lain. Tetapi pada dasarnya, metrik yang sangat dibutuhkan adalah uang. Uang paling penting untuk bisnis.
Biasanya, kriteria untuk kesuksesan bisnis adalah sesuatu yang pada akhirnya melibatkan uang:
- keuntungan;
- penghasilan
- biaya
- efektivitas.
Metrik bisnis:
- Pendaftaran
- pembelian;
- tampilan iklan
- konversi;
- persentase pengembalian;
- jumlah bir yang diminum
Semua ini memiliki persamaan moneter.Ngomong-ngomong, kemungkinan besar, semua metrik ini sudah dikumpulkan di perusahaan Anda - baik dengan penjualan atau pemasaran. Jadi Anda tidak perlu menciptakan roda, Anda bisa mengambil metrik yang ada ke sistem Anda sendiri.
Semuanya harus dipertimbangkan dalam konteks bisnis. Kami berbicara tentang metrik khusus untuk bisnis. Lainnya, yaitu metrik teknis, juga dapat dipertimbangkan dalam konteks ini.
Misalnya, kecepatan unduh adalah jadwal yang cukup standar. Pada awalnya semuanya beres, naik-turun, naik-turun, dan tiba-tiba masalah yang jelas. Itu diperbaiki, dan jadwal kembali ke bentuk standar - persentil ke-99 di bawah ambang batas, SLA tidak dilanggar.
Jika Anda mengambil jadwal yang sama dan melihat jumlah pengguna yang terpengaruh, masalahnya langsung terlihat berbeda.
, . , , , . , .
. , . . . , 3 , .
— . , , , , .
.
: , , , - .
, . , , , 50 % « », , .
1 ?
1-2 . . 10 000 , . , 10 000 , - .
1 . 600-700 . , 600 — , . , , . 800 , , — .
, , . 0 , - , ! .
, - . — , .
99- 50- , . , .
, — , DevOps — .
, , .
Value stream mapping — . , . , , , , , . , , .
:
- MTTD (mean time to discovery) — , .
- MTTR (mean time to recovery) — , .
- , .
- / .
, , , , . : « — . , , ».
, , . , .
. , — , , . , . .
— , , . , , , . — .
1 2 , DevOpsConf Russia .
DevOps, , , . , , .
, , .