Tragedi (dari
Tragödie Jerman dari
tragoedia Latin dari
τραγωδία Yunani lainnya ) adalah genre karya seni yang ditujukan untuk pementasan di panggung di mana plot membawa karakter ke hasil bencana.
Kebanyakan tragedi ditulis dalam ayat. Tragedi ini ditulis oleh Baruch Sadogursky (
@jbaruch ) dan Leonid Igolnik (
@ligolnik ). Jika kita berbicara tentang DevOps dalam skala besar, apa itu selain tragedi?
Artikel ini ditandai oleh kerasnya realisme, menggambarkan realitas perkembangan besar paling tajam, seperti sekelompok kontradiksi internal. Ini mengungkapkan konflik realitas terdalam dalam bentuk yang sangat intens dan jenuh, memperoleh nilai simbol artistik.
Dan sekarang kita selesai bermain Belinsky dan selamat datang di cut! Ada teks dan video. Jangan sandera!
Seperti yang Anda tahu, orang-orang Yunani memuja diagram Venn. Dan kami akan menunjukkan kepada Anda sebanyak tiga - dan semua tentang DevOps.
Ada deskripsi tradisional DevOps - ini adalah persimpangan area Operasi, Pengembangan dan QA. Secara historis menarik bahwa QA ditambahkan di sana nanti.
Tetapi hari ini kita akan berbicara tentang sesuatu yang lain - persimpangan teknologi, proses dan orang-orang. Tentang apa yang perlu Anda lakukan dengan ketiga komponen ini untuk mendapatkan DevOps.
Sekarang bandingkan dua grafik lagi:
Terkadang itu terjadi.
Pentagon Inc.
Mari kita mulai cerita dengan perusahaan mitos bernama Pentagon, yang berurusan dengan transaksi kartu kredit.
Babak I - Pemadam Kebakaran
Orang Perusahaan baru memulai pekerjaannya, ia memiliki tiga insinyur. Ketiganya berasal dari perusahaan pertahanan yang sama. Mereka cukup pintar, sehingga mereka memiliki segalanya: JavaScript, Node, React, Docker, microservices.
Proses Seperti apa prosesnya ketika ada tiga orang dalam satu tim? Kanban: baik di selembar kertas atau Trello. Mereka cerdas dan mengerti bahwa QA diperlukan sejak awal, oleh karena itu TDD, unit & tes integrasi. Tanpa ops, semuanya memiliki root.
Alat Dengan demikian, untuk tiga orang yang baru saja mengangkat sesuatu:
JIRA ,
GitHub ,
Travis CI , dll.
Mari kita bicara tentang bagaimana orang-orang ini hidup di tumpukan yang indah ini. Pertama, seperti pada startup yang baik - kami menggergaji, menggergaji suatu produk dan menunggu klien pertama.
Tiba-tiba, keajaiban terjadi - satu organisasi yang menyelenggarakan konferensi terbaik di ruang pasca-Soviet memutuskan untuk mempercayai orang-orang ini dan melakukan transaksi melalui mereka.
Apa yang dilakukan startup nyata ketika mendapat klien pertama? Merayakan! Dan di suatu tempat sekitar tiga malam, ketika semuanya dalam keadaan
khusus , klien menelepon dan mengatakan bahwa tidak ada yang berfungsi.
Tentu saja, pertama-tama, panik!
Langkah selanjutnya adalah bertarung! Kami melihat log, misalnya.
Kami melihat, melihat, ternyata salah satu dari tiga pahlawan kami - Vasya, setelah pulang setelah festival, melakukan gagasan kecilnya. Kita ingat bahwa setelah komit dan tes berlalu, semuanya terbang ke produksi.
Nah, siapa di antara kita yang tidak gagal produksi? Kami tidak akan menyalahkan Vasya. Kembalikan ke komit sebelumnya. Itu tidak akan! Untuk beberapa alasan, tidak ada cukup perpustakaan, yang disebut pad kiri.
Bagi mereka yang tidak tahu apa yang terjadi pada pad-kiri, kami beri tahu. Jadi,
pada 23 Maret 2016, separuh dari Internet terputus . Secara umum, modul pad kiri dalam JavaScript hanya menyisipkan spasi di sisi kiri garis. Dan setengah dari Internet bergantung secara langsung atau transitif pada modul ini. Penulis kiri-entah bagaimana berhasil bertengkar dengan pemilik repositori npm pusat, jadi dia hanya berjalan menjauh dari mereka, mengambil semua pekerjaannya. npm pada umumnya adalah sistem misterius: mereka tidak hanya memeriksa ketika Anda menambahkan modul baru untuk diunduh, mereka juga memeriksa semua modul lama.
Jadi, dari waktu ke waktu, perang melawan api terus berlanjut. Dan masalahnya sama sepanjang waktu.
Act II - Pemasang Alarm Kebakaran
Berita perusahaan: mengangkat adonan, menemukan seorang investor, mempekerjakan 27 orang, salah satunya dengan latar belakang operasi. 100 klien muncul dan bahkan dukungan teknis.
Prosesnya, karenanya, juga harus mendapatkan peningkatan. Scrum normal, pengujian eksplorasi, muncul. Kami menyadari bahwa NoOps tidak ada sama sekali, karena ada Ops (jika arsitektur serverless, maka server masih ada, itu bukan milik Anda). Karena salah membangunkan seluruh tim di malam hari, pengembang yang dipanggil muncul.
Dengan demikian, seperangkat alat telah diperluas. Paling tidak, Basis Pengetahuan telah muncul, karena sekarang ada petugas, dan dia perlu mencari informasi di suatu tempat. Hal baru lainnya adalah
JFrog Artifactory : sebuah sistem yang memungkinkan Anda untuk menyimpan apa yang dipasok kemarin sehingga Anda dapat dengan mudah memutar kembali (pelajaran dengan bantalan kiri tidak sia-sia), daripada membangunnya kembali. Kami memasukkan sistem untuk mengumpulkan log dan mencarinya.
Pingdom telah ditambahkan - sistem pemantauan yang mempesona: Anda memberinya url, dan memberitahu Anda apakah itu berfungsi atau macet.
Jadi, pada titik ini mereka mengumpulkan uang lagi. Jadi, kami perhatikan. Jumat, pukul tiga dini hari, pelanggan menelepon. Sesuatu tidak berfungsi: Visa dan MasterCard lulus, tetapi American Express tidak.
Dan bagaimana reaksi pertama kali bereaksi ketika seorang pelanggan menelepon pada pukul tiga pagi? Panik!
Lalu kami memanggil petugas. Tebak siapa yang bertugas? Tentu saja, Vasya! Coba tebak negara bagian Vasya. Ya Tapi Vasya menenangkan diri, melihat apa yang telah dikirim dukungan kepadanya, dan mengatakan bahwa dia semua akrab dengan ini dan dia sudah melakukan ini. Karena itu, Vasya hanya mengambil dan memperbaiki. Semua orang akan tidur. Pembekalan dimulai pada hari Senin.
Berikut ini adalah contoh dari dokumen spesifik yang kami hasilkan untuk basis pengetahuan, sehingga jika sesuatu terulang lagi, ia dapat ditemukan dengan cepat. Selain itu, terkadang ditampilkan ke pelanggan:
Dokumen ini menampilkan judul utama, alasan, karakteristik, daftar acara. Gejala harus diindikasikan, deskripsi teknis diberikan tentang apa yang benar-benar rusak dan bagaimana cara memperbaikinya. Bagian terpenting dari dokumen adalah alasan utama mengapa sesuatu jatuh.
Dalam kasus Vasya, kami memiliki log queue overflow. Anda perlu menghapusnya dari transaksi kartu kredit, dan di samping itu, memperbesar ukurannya. Misalnya, pada usia 42!
Proses seperti itu sangat baik untuk perbaikan internal yang berkelanjutan dan menjamin pemasangan "detektor asap" yang sama. Alasan kedua dokumen ini penting adalah laporan kepada klien. Beberapa layanan, setelah mereka "berbaring" sebentar, mempublikasikan alasan untuk ini.
Kadang-kadang masalahnya ternyata begitu dahsyat sehingga tidak layak untuk membicarakannya.
Di GitLab
pada Februari 2017 , seseorang menghapus basis data produksi. Berikut adalah analisis yang diunggah GitLab:
Jadi, di suatu tempat ada cadangan, hanya saja tidak ada yang tahu di mana. Kemudian cadangan ditemukan, tetapi ternyata kosong. Ya, ada tempat pembuangan sampah. Tapi itu dibuat dalam versi postgres yang berbeda, jadi tidak cocok. Kami memiliki snapshot, tetapi mereka tidak memiliki database. Replikasi dari S3 tidak berhasil karena kurangnya data.
Dengan demikian, lima teknik berbeda untuk membuat cadangan data tidak berhasil. Kami pikir ini tidak dapat dipublikasikan, karena tidak ada orang lain yang akan mempercayai mereka. Tetapi, tergantung pada bagaimana Anda membicarakannya, klien mungkin memaafkan. Benar, hanya sekali.
Ngomong-ngomong, pria yang melakukannya mendapat promosi. Selain itu, ia mengubah status twitter-nya menjadi
Spesialis Database (penghapusan) di GitLab .
Babak III - Klimaks
Jadi apa yang terjadi di perusahaan kita? Mereka mengumpulkan uang lagi, merekrut sekelompok orang - sekarang kami memiliki lima insinyur ops dan satu orang yang terlibat dalam kinerja. Ada kepala arsitek. Tim sukses pelanggan telah muncul, yang mencakup semua industri yang mungkin membutuhkan dukungan. Mereka melambat sehingga anggota tim lainnya dapat terus bekerja. Seringkali dalam tim seperti itu ada kelompok yang dapat membangun hubungan dengan ops atau dukungan, dan juga secara berkala di sana Anda perlu menurunkan insinyur pada scrum, atau sprint, atau selama sebulan. Perusahaan tumbuh, seorang pengacara, seorang direktur keuangan muncul. Basis pelanggan telah berkembang menjadi 1000.
Seiring pertumbuhan tim, proses pengembangan harus berubah.
SAFE muncul - kerangka kerja yang menjelaskan apa yang harus dilakukan scrum ketika ada banyak tim atau pusat pengembangan - lebih dari satu. Jumlah proses yang ada di Safe dapat membunuh seekor kuda, tetapi jika semuanya bisa diambil sekaligus. Jika Anda hanya mengambil bagian-bagian yang diperlukan pada tahap pengembangan perusahaan ini, maka semuanya akan baik-baik saja.
Pengujian sistem muncul ketika tim besar memiliki kebutuhan tertentu atau jika Anda memiliki sistem besar tempat Anda perlu membangun sesuatu. Masing-masing tim scrum dapat menguji sistem mereka dengan baik, tetapi seseorang harus bertanggung jawab atas kenyataan bahwa keseluruhan sistem harus dirakit dalam produksi.
Bagaimana dengan Tim Ops? Seperti yang kami katakan, ada dua opsi untuk melakukan DevOps. Yang pertama adalah untuk buku dan untuk instruksi dari Netflix, Google, dan Twitter. Yang kedua adalah dalam kehidupan nyata, di mana tidak semua insinyur dapat dipercaya dengan akar dalam produksi.
Jalur eskalasi adalah konsep penting yang memungkinkan Anda untuk menyelesaikan masalah pada waktu tertentu, karena pada akhir jalur eskalasi ada telepon seluler CEO, setelah panggilan ke mana semua masalah hilang dalam 5 jam 58 menit.
SOC II - seperangkat standar yang disediakan vendor kepada klien. Standar-standar ini menegaskan bahwa perusahaan memiliki solusi keamanan tertentu, pendekatan untuk pembagian kerja.
Backlog - daftar masalah yang perlu ditangani untuk meningkatkan sistem. Biasanya arsitek belakang menjadi arsitek utama, yang harus melihat kebutuhan sistem dan kebutuhan produk dan memprioritaskan tugas-tugas ini.
Alat, tentu saja, juga sedang diperbaiki.
Ada lebih banyak berita. Vasya dipromosikan. Dia sekarang adalah Wakil Presiden bidang Teknik.
Jumat, Sabtu, Minggu berlalu - tidak ada yang datang. Semuanya berfungsi. Semua orang kaget. Senin datang, seorang pengacara datang ke Vasya dan mengatakan bahwa ia berada di sebuah konferensi pengacara dan mendengar tentang LGPL 2.2 di sana. Vasya tidak tahu jika mereka memiliki LGPL 2.2.
Orang-orang bekerja untuk waktu yang lama, dan kemudian menemukan LGPL 2.2. Perlu dipotong. Tapi ini sedang dipotong oleh sistem yang sehat, dan tidak ada yang membatalkan rilis besok. Yah, tidak ada, berurusan dengan ini.
Direktur dana datang ke Vasya:
- Berapa banyak uang yang Anda butuhkan untuk server dan produksi? Membuat anggaran untuk tahun depan ...
- 42 - kata Vasya.
Kami juga memecahkan masalah ini.
Mereka datang ke Vasya dan mengatakan bahwa ada klien potensial, tetapi dia takut bahwa kita tidak pernah memiliki pelanggan skala besar, dan ingin diyakinkan bahwa itu akan baik. Kita tahu dari sejarah bahwa pada tahap ini setiap orang mati.
Tetapi karena kita harus memiliki akhir yang bahagia, kita mengaitkannya dengan tragedi Yunani.
Epilog - Perbaikan Proaktif
Sekarang mari kita bicara tentang tahap terakhir penskalaan DevOps - Peningkatan Proaktif. Ini tentang pencegahan kebakaran.
Tidak ada perubahan yang terjadi pada orang. Tetapi dengan proses - sangat banyak.
Karena kami memiliki Insinyur Kinerja, entah bagaimana ia harus memantau sistem. Manajemen lisensi dan keamanan muncul. Kinerja Proaktif - sekarang kami dengan cermat mengamati di mana indikator utama bergerak dan memperbaiki hal-hal sebelum kebakaran besar dimulai. Ketika meningkatkan produk, disarankan untuk memiliki sesuatu yang mengatakan: jika Anda ingin memiliki layanan mikro, maka setidaknya itu harus memiliki pemantauan standar, log dan sebagainya.
Karenanya, ada alat yang mendukung semua ini. Sebagai contoh, alat untuk lisensi dan pemantauan keamanan adalah
JFrog Xray .
Blazemeter - karena sekarang ada kinerja proaktif, Anda perlu entah bagaimana menghasilkan beban. Hal-hal muncul seperti Layanan Virtualisasi, yang memungkinkan Anda untuk menggunakan objek tiruan untuk API jarak jauh, karena tidak setiap vendor yang bekerja dengan Anda dapat menyediakan API pengujian.
Parsing
Mari kita menganalisis beberapa peristiwa dari tindakan sebelumnya.
Ingat kasus ketika Vasily merencanakan anggaran dengan jari di langit? Dalam mengerjakan salah satu produk kami, kami ingin mengetahui sumber daya apa yang dihabiskan. Setelah mengelompokkan semua yang ada di tumpukan, kami mendapatkan diagram ini:
Kami keliru berpikir bahwa kami menghabiskan 80% untuk Fitur Besar A - pada kenyataannya, hanya butuh 13%. Pada saat yang sama, sebanyak 34% digunakan untuk Menyalakan lampu - hal-hal yang perlu dilakukan dalam produk: memperbaiki bug, memperbarui perpustakaan, dll.
Bahkan, hanya ada satu metrik objektif kualitas produk: kepuasan pelanggan, yang dinyatakan dalam panggilan untuk mendukung.
Contoh kedua. Kami memecahkan semua cacat kritikalitas:
65% tiket milik tingkat kritis pertama. Apakah ini mimpi buruk?
Sekarang ambil data yang sama dan lihat dari sudut yang berbeda.
Sekarang bagan mencerminkan situasi setelah pembekalan. Ternyata 52% tiket ditutup oleh insinyur menggunakan informasi yang disediakan, yaitu, ia menulis kepada pendukung apa yang tidak mereka ketahui. Hanya sekitar 20% tiket ditutup dengan semacam perubahan kode. Jadi, ternyata R&D tidak salah. Bahkan dukungannya tidak bisa disalahkan. Faktanya, kami kekurangan pelatihan - dan Vasya, seperti Wakil Presiden bidang teknik, setelah melihat berapa banyak ia menghabiskan waktu untuk semua jenis omong kosong, ia mengirim banyak insinyur untuk melatih dukungan.
Orang-orang mengoreksi dokumentasi di bottlenecks, mengoreksi log. Akibatnya, karya itu, yang menghabiskan banyak waktu bagi pengembang, menghilang.
Kesimpulan
Di semua tahap, mulai dari pemadaman kebakaran hingga pemasangan alarm dan penyelesaian masalah proaktif, ada banyak proses, orang, spesialis, pendekatan, alat yang perlu dipasang. Semua ini tidak bisa dilakukan dalam satu hari. Selain itu, beberapa hal tidak diperlukan pada beberapa tahap perkembangan.
Penting untuk dipahami bahwa dalam diri orang, dan dalam proses, dan dalam alat, beberapa perbaikan terus-menerus diperlukan.
Apa yang sebenarnya perlu diperbaiki, kita akan dibantu untuk mengetahui angka yang kita bicarakan. Hanya berdasarkan data ini kita dapat membuat keputusan yang tepat tentang di mana harus menginvestasikan waktu dan apa yang akan bergerak maju.
Dan jangan lupakan dua prinsip dasar DevOps:
- Anda membangunnya - Anda memilikinya.
- Nyeri bersifat instruksional.
Minggu berikutnya, Baruch dan Leonid akan menyampaikan laporan "#DataDrivenDevOps" di DevOops 2018 di St. Petersburg. Ayo, akan ada banyak hal menarik: inilah laporannya , inilah John Willis , dan di sini ada pesta dengan BoF dan karaoke . Menunggu kamu!