Ini adalah artikel kedua dari seri "Citymobil - manual untuk meningkatkan ketersediaan di tengah pertumbuhan bisnis untuk startup." Anda dapat membaca bagian pertama di
sini . Mari kita terus berbicara tentang cara kami berhasil meningkatkan ketersediaan layanan Citymobil. Pada artikel pertama, kami belajar bagaimana cara menghitung perjalanan yang hilang. Oke, kami menghitungnya. Apa sekarang? Sekarang kita dilengkapi dengan alat yang dapat dimengerti untuk mengukur perjalanan yang hilang, kita dapat pindah ke bagian yang paling menarik - bagaimana kita mengurangi kerugian? Tanpa memperlambat pertumbuhan kita saat ini! Karena tampaknya bagi kami bahwa bagian terbesar dari masalah teknis yang menyebabkan hilangnya perjalanan ada hubungannya dengan backend, kami memutuskan untuk mengalihkan perhatian kami ke proses pengembangan backend terlebih dahulu. Melompati diri saya sendiri, saya akan mengatakan bahwa kami benar - backend menjadi situs utama pertempuran untuk perjalanan yang hilang.
1. Bagaimana proses pengembangan bekerja
Masalah biasanya disebabkan oleh penyebaran kode dan tindakan manual lainnya. Layanan yang tidak pernah diubah dan disentuh dengan tangan kadang-kadang juga kegagalan fungsi, itu pengecualian yang hanya membuktikan aturan.
Dalam pengalaman saya, pengecualian yang paling menarik dan tidak biasa adalah sebagai berikut. Kembali ke tahun 2006, ketika saya bekerja di salah satu layanan webmail kecil, ada gateway yang proksi semua lalu lintas dan memastikan alamat IP tidak ada dalam daftar hitam. Layanan ini bekerja pada FreeBSD dan bekerja dengan baik. Tetapi suatu hari itu berhenti bekerja. Tebak kenapa? Disk di mesin ini gagal (blok buruk telah terbentuk untuk sementara waktu dan hal yang tak terhindarkan terjadi) dan itu terjadi tiga tahun sebelum kegagalan layanan. Semuanya hidup dengan disk yang gagal. Dan kemudian FreeBSD, untuk alasan yang hanya diketahui oleh dirinya sendiri, tiba-tiba memutuskan untuk mengatasi disk yang gagal dan berhenti sebagai hasilnya.
Ketika saya masih kecil, 10-12 tahun, saya pergi hiking ke hutan bersama ayah saya dan mendengar ungkapan darinya bahwa saya tidak pernah lupa: "semua yang perlu Anda lakukan untuk menjaga api unggun tetap menyala bukan menyentuhnya". Saya percaya sebagian besar dari kita dapat mengingat situasi ketika kita memberi makan kayu ke api yang sudah terbakar dan itu akan padam tanpa alasan.
Intinya adalah masalah diciptakan oleh tindakan manual manusia; misalnya, ketika Anda memberi makan kayu ke api unggun yang sudah menyala dengan baik sehingga memotong oksigen dan membunuh api atau dengan menyebarkan kode dengan bug ke dalam produksi. Oleh karena itu, untuk memahami apa yang menyebabkan masalah layanan, kita perlu memahami cara kerja proses pengembangan dan pengembangan.
Di Citymobil, prosesnya sepenuhnya berorientasi pada pengembangan dan terorganisir dengan cara berikut:
- 20-30 rilis per hari.
- Pengembang melakukan penyebaran sendiri.
- Pengujian cepat di lingkungan pengujian oleh pengembang.
- Tes unit / otomatis minimum, peninjauan minimum.
Pengembang bekerja dalam kondisi yang sulit tanpa dukungan QA, dengan aliran tugas yang sangat penting dari tim produk dan eksperimen; mereka bekerja sekuat dan sekonsisten mungkin, mereka menyelesaikan tugas-tugas sulit dengan cara yang sederhana, mereka memastikan bahwa kode tidak berubah menjadi spageti, mereka memahami masalah bisnis, menangani perubahan secara bertanggung jawab dan dengan cepat mengembalikan apa yang tidak berhasil. Tidak ada yang baru di sini. Ada situasi yang sama di layanan Mail.Ru 8 tahun yang lalu ketika saya mulai bekerja di sana. Kami memulai
Mail.ru Cloud dengan cepat dan mudah, tanpa pembuka. Kami akan mengubah proses kami di jalan untuk mencapai ketersediaan yang lebih baik.
Saya yakin Anda telah memperhatikan hal itu sendiri: ketika tidak ada pegangan dilarang, saat itu hanya Anda dan produksi, ketika Anda membawa beban tanggung jawab yang besar - Anda melakukan keajaiban. Saya sudah memiliki pengalaman seperti itu. Dulu saya hanya satu-satunya pengembang di layanan webmail Newmail.Ru (diakuisisi beberapa waktu lalu dan kemudian dihapus); Saya melakukan penyebaran sendiri dan melakukan pengujian produksi pada diri saya sendiri melalui
if (!strcmp(username, "danikin")) { … some code… } . Jadi, saya terbiasa dengan situasi ini.
Saya tidak akan terkejut mengetahui bahwa pendekatan "cepat dan kotor" seperti itu telah digunakan oleh banyak startup baik yang sukses maupun yang tidak, tetapi semuanya didorong oleh satu semangat - keinginan untuk pertumbuhan bisnis yang cepat dan pangsa pasar.
Mengapa Citymobil melakukan proses seperti itu? Hanya ada sedikit pengembang untuk memulai. Mereka telah bekerja untuk perusahaan untuk sementara waktu dan tahu kode dan bisnis dengan sangat baik. Proses ini bekerja secara ideal dalam kondisi tersebut.
2. Mengapa ancaman ketersediaan muncul?
Pertumbuhan investasi ke dalam pengembangan produk disebabkan oleh rencana produk kami untuk menjadi lebih agresif dan kami mulai merekrut lebih banyak pengembang. Jumlah penyebaran per hari meningkat, tetapi secara alami kualitas mereka menurun karena orang-orang baru harus terjun ke dalam sistem dan bisnis dalam kondisi lapangan. Peningkatan jumlah pengembang menghasilkan tidak hanya linear, tetapi penurunan kuadrat dalam ketersediaan (jumlah penyebaran tumbuh secara linear, dan kualitas penyebaran rata-rata menurun secara linear, sehingga "linear" * "linear" = "kuadrat").
Jelas, kami tidak bisa terus seperti itu. Prosesnya tidak dibangun untuk kondisi baru ini. Namun, kami harus memodifikasinya tanpa kompromi waktu ke pasar; yaitu, mempertahankan 20-30 rilis per hari (mengingat jumlah mereka akan bertambah saat tim bertambah). Kami tumbuh dengan cepat, kami melakukan banyak percobaan, segera mengevaluasi hasilnya dan melakukan percobaan baru. Kami dengan cepat menguji hipotesis produk dan bisnis, belajar darinya dan membuat hipotesis baru yang segera kami uji lagi dan seterusnya. Dalam situasi apa pun kita tidak akan melambat. Selain itu, kami ingin mempercepat dan merekrut pengembang lebih cepat. Jadi, tindakan kami yang ditujukan pada pertumbuhan bisnis menciptakan ancaman ketersediaan, tetapi kami sama sekali tidak memiliki niat untuk memodifikasi tindakan ini.
3. Ok, tugas sudah diatur, prosesnya jelas. Apa selanjutnya
Memiliki pengalaman bekerja di layanan email Mail.Ru dan Cloud Mail.Ru di mana ketersediaan di beberapa titik telah menjadi prioritas nomor satu, di mana penyebaran dilakukan sekali setiap minggu, di mana semuanya tercakup oleh pengujian unit dan otomatis dan kode ditinjau setidaknya sekali, tetapi kadang-kadang bahkan tiga kali, saya menghadapi situasi yang sama sekali berbeda.
Anda akan berpikir semuanya cukup sederhana: kita bisa meniru proses email / cloud Mail.Ru di Citymobil sehingga meningkatkan ketersediaan layanan. Namun, seperti yang mereka katakan - iblis ada dalam rincian:
- penyebaran di Mail.Ru email / cloud dilakukan seminggu sekali, bukan 30 kali sehari; di Citymobil kami tidak ingin mengorbankan kuantitas rilis;
- dalam email / cloud Mail.Ru kode dilindungi oleh uji otomatis / unit dan kami tidak punya waktu atau sumber daya untuk itu di Citymobil; kami melemparkan semua upaya pengembangan backend kami ke hipotesis dan pengujian peningkatan produk.
Yang mengatakan, kami bertangan pendek dalam hal pengembang backend, meskipun mereka disewa segera (terima kasih khusus kepada perekrut Citymobil - perekrut terbaik di dunia! Saya pikir akan ada artikel terpisah tentang proses rekrutmen kami) , jadi tidak mungkin kami dapat mengatasi masalah pengujian dan peninjauan tanpa melambat.
4. Ketika Anda tidak tahu apa yang harus dilakukan, belajarlah dari kesalahan
Jadi, apa yang ajaib yang kami lakukan di Citymobil? Kami memutuskan untuk belajar dari kesalahan. Metode peningkatan layanan belajar-dari-kesalahan adalah setua waktu. Jika sistem bekerja dengan baik, itu bagus. Jika sistem tidak bekerja dengan baik, itu juga bagus karena kita bisa belajar dari kesalahan. Lebih mudah diucapkan daripada ... Sebenarnya, itu bisa dilakukan dengan mudah juga. Kuncinya adalah menetapkan tujuan.
Bagaimana kita belajar? Pertama, kami mulai secara religius menuliskan informasi pada setiap pemadaman, besar dan kecil. Sejujurnya, saya benar-benar tidak ingin melakukan itu pada awalnya karena saya berharap untuk keajaiban dan berpikir bahwa pemadaman akan berhenti sendiri. Jelas, tidak ada yang berhenti. Realitas baru tanpa ampun menuntut beberapa perubahan.
Kami mulai mencatat semua pemadaman dalam tabel Google Documents. Untuk setiap pemadaman ada informasi singkat berikut:
- tanggal, waktu, durasi;
- akar penyebabnya;
- apa yang dilakukan untuk memperbaiki masalah;
- dampak bisnis (jumlah perjalanan yang hilang, hasil lainnya);
- takeaways.
Untuk setiap pemadaman besar, kami akan membuat file besar yang terpisah dengan deskripsi menit demi menit yang terperinci dari saat pemadaman dimulai sampai saat berakhirnya: apa yang kami lakukan, keputusan apa yang diambil. Ini biasanya disebut post-mortem. Kami akan menambahkan tautan ke post-mortem ini ke dalam tabel umum.
Ada satu alasan untuk membuat file seperti itu: untuk membuat kesimpulan yang bertujuan mengurangi jumlah perjalanan yang hilang. Sangatlah penting untuk menjadi sangat spesifik tentang apa yang "penyebab utama" dan apa yang "menjadi takeaways". Arti kata-kata ini jelas; Namun, setiap orang dapat memahaminya secara berbeda.
5. Contoh pemadaman yang telah kita pelajari
Akar permasalahan adalah masalah yang perlu diperbaiki untuk menghindari kecelakaan seperti itu di masa depan. Dan kesimpulan - cara untuk menghilangkan akar penyebab atau mengurangi kemungkinan kebangkitannya.
Akar penyebabnya selalu lebih dalam dari yang seharusnya. Para takeaways selalu lebih rumit daripada yang tampaknya. Anda seharusnya tidak pernah puas dengan dugaan ditemukan penyebab utama dan tidak pernah puas dengan dugaan pernyataan, sehingga Anda tidak rileks dan berhenti pada apa yang tampaknya benar. Ketidakpuasan ini menciptakan percikan untuk analisis lebih lanjut.
Biarkan saya memberi Anda contoh dunia nyata: kami menyebarkan kode, semuanya turun, kami memutar kembali, semuanya bekerja kembali. Apa akar masalahnya? Anda akan mengatakan:
Penempatan. Jika Anda tidak menggunakan kode, maka tidak akan ada kecelakaan. Jadi, apa masalahnya: tidak ada lagi penyebaran? Itu takeaway yang tidak terlalu bagus. Jadi, kemungkinan besar, itu bukan akar masalahnya, kita perlu menggali lebih dalam.
Penempatan dengan bug. Itulah akar masalahnya? Baiklah Bagaimana cara memperbaikinya? Anda akan mengatakan dengan pengujian. Tes seperti apa? Misalnya - uji regresi penuh untuk semua fungsionalitas. Ini takeaway yang baik, mari kita ingat. Tetapi kita perlu meningkatkan ketersediaan di sini dan sekarang sebelum kita menerapkan uji regresi penuh. Kita perlu menggali lebih dalam lagi.
Penempatan dengan bug yang disebabkan oleh debug cetak di tabel database; kami kelebihan beban basis data, dan itu turun di bawah beban. Itu terdengar lebih baik. Sekarang menjadi jelas bahwa bahkan uji regresi penuh tidak akan menyelamatkan kita dari masalah ini. Karena tidak akan ada beban kerja pada database uji yang mirip dengan beban kerja produksi.
Apa akar penyebab masalah ini, jika kita menggali lebih dalam? Kami harus berbicara dengan insinyur untuk mengetahuinya. Ternyata, insinyur itu terbiasa dengan database yang mampu menangani beban kerja apa pun. Namun, karena pertumbuhan beban kerja yang cepat, basis data tidak dapat menangani apa yang ditangani sehari sebelumnya. Sangat sedikit dari kita memiliki kesempatan untuk bekerja untuk proyek-proyek dengan tingkat pertumbuhan 50% per bulan. Bagi saya, misalnya, itu adalah proyek pertama seperti itu. Setelah terjun ke proyek seperti itu, Anda mulai memahami realitas baru. Anda tidak akan pernah tahu itu di luar sana sampai Anda menemukannya.
Insinyur datang dengan cara yang benar untuk memperbaikinya: debug cetak harus dilakukan dalam file yang harus ditulis melalui skrip cron ke database dalam satu utas. Jika ada terlalu banyak pencetakan debug, basis data tidak akan turun; data debug hanya akan muncul cepat atau lambat. Insinyur ini jelas telah belajar dari kesalahannya dan tidak akan berhasil lagi. Tetapi insinyur lain juga harus tahu tentang itu. Bagaimana? Mereka perlu diberi tahu. Bagaimana membuat mereka mendengarkan? Dengan menceritakan keseluruhan kisah dari awal hingga akhir, dengan menguraikan konsekuensi dan mengusulkan cara yang benar untuk melakukannya; dan juga, dengan mendengarkan dan menjawab pertanyaan mereka.
6. Apa lagi yang bisa kita pelajari dari kesalahan ini atau "lakukan & tidak boleh dilakukan".
Ok, mari kita terus menganalisis pemadaman ini. Perusahaan ini berkembang pesat, insinyur baru datang. Bagaimana mereka akan belajar dari kesalahan ini? Haruskah kita memberi tahu setiap insinyur baru tentang hal itu? Jelas, akan ada semakin banyak kesalahan - bagaimana kita membuat semua orang belajar darinya? Jawabannya hampir jelas: buat file yang harus dan tidak boleh dilakukan. Kami akan menulis semua takeaways ke file ini. Kami menunjukkan file ini kepada semua insinyur baru kami dan juga kepada semua insinyur kami saat ini dalam obrolan kelompok kerja setiap kali daftar larangan dan larangan dilakukan, sangat mendesak semua orang untuk membacanya lagi (untuk membaca informasi lama dan melihat baru).
Anda mungkin mengatakan bahwa tidak semua orang akan membaca dengan cermat. Anda mungkin mengatakan bahwa mayoritas akan melupakannya setelah membaca. Dan Anda akan benar di kedua akun. Namun, Anda tidak dapat menyangkal fakta bahwa sesuatu akan melekat di kepala seseorang. Dan itu cukup bagus. Dalam pengalaman Citymobil, para insinyur menangani file ini dengan sangat serius dan situasi ketika beberapa pelajaran dilupakan sangat jarang terjadi. Fakta bahwa pelajaran itu dilupakan dapat dilihat sebagai masalah; kita harus menarik kesimpulan dan menganalisis detail untuk mencari cara mengubah sesuatu di masa depan. Penggalian semacam ini menghasilkan kata-kata yang harus dan tidak boleh dilakukan yang lebih tepat dan akurat.
Pengambilan dari pemadaman yang dijelaskan di atas: buat file harus dan tidak boleh dilakukan; tulis semua yang telah kita pelajari di dalamnya, perlihatkan file ke seluruh tim, minta setiap pendatang baru untuk mempelajarinya dan mendorong orang untuk bertanya.
Saran umum yang kami peroleh dari tinjauan pemadaman: sebaiknya kita tidak menggunakan kombinasi kata "sial terjadi". Segera setelah Anda mengatakannya dengan keras, semua orang memutuskan bahwa tidak ada yang perlu dilakukan, tidak ada kesimpulan yang diperlukan karena manusia selalu membuat kesalahan, membuat kesalahan sekarang dan akan membuat mereka di masa depan. Karena itu, alih-alih mengatakan kalimat itu, Anda harus membuat
kesimpulan khusus. Kesimpulan - mungkin kecil tetapi masih merupakan langkah ke arah perbaikan proses pengembangan, sistem pemantauan dan alat otomatis. Langkah kecil seperti itu menghasilkan layanan yang lebih stabil!
7. Sebagai pengganti epilog
Pada bagian selanjutnya, saya akan berbicara tentang jenis pemadaman dalam pengalaman Citymobil dan menjelaskan secara terperinci tentang setiap jenis pemadaman; Saya juga akan memberi tahu Anda tentang kesimpulan yang kami buat tentang pemadaman, bagaimana kami memodifikasi proses pengembangan, otomatisasi apa yang kami perkenalkan. Tetap disini!