⚫️ 🛀 👩‍❤️‍💋‍👨 Citymobil - manual untuk meningkatkan ketersediaan di tengah pertumbuhan bisnis untuk startup. Bagian 5 ➡️ 😶 💸

Ini adalah bagian terakhir dari seri yang menggambarkan bagaimana kami meningkatkan ketersediaan layanan kami di Citymobil (Anda dapat membaca bagian sebelumnya di sini ). Sekarang saya akan berbicara tentang satu jenis pemadaman lagi dan kesimpulan yang kami buat tentang mereka, bagaimana kami memodifikasi proses pengembangan, otomatisasi apa yang kami perkenalkan.

1. Rilis buruk: bug

Ini adalah jenis pemadaman dan insiden yang paling tidak menyenangkan. Satu-satunya jenis yang tidak memiliki gejala yang terlihat selain keluhan pengguna akhir atau pengguna bisnis. Itu sebabnya insiden seperti itu, terutama yang kecil, dapat tetap tidak diperhatikan dalam produksi untuk sementara waktu.

Semua jenis pemadaman lainnya kurang lebih mirip dengan "Rilis buruk: 500 kesalahan server internal". Satu-satunya hal adalah mereka tidak dipicu oleh rilis, melainkan beban kerja, operasi manual atau masalah layanan eksternal.

Untuk menjelaskan metode mengatasi gangguan seperti ini, kita harus mengingat lelucon lama:

Seorang ahli matematika dan ahli fisika diberikan tugas yang sama: merebus air. Mereka diberi beberapa alat bantu: kompor, ketel, keran dengan air, korek api. Keduanya bergiliran mengisi ketel dengan air, menyalakan gas dan mulai memanaskan ketel. Kemudian tugas disederhanakan: mereka diberi ketel, diisi dengan air dan kompor yang sudah menyala. Tugasnya sama - merebus air. Fisikawan meletakkan ketel di atas kompor. Matematikawan mengosongkan ketel, mematikan gas dan berkata: "Masalahnya berkurang menjadi yang sudah dipecahkan." © anekdotov.net

Jenis pemadaman ini harus dikurangi menjadi "Rilis buruk: 500 kesalahan server internal" di semua biaya. Idealnya, bug harus dicatat dengan cara yang sama seperti 500 kesalahan. Namun, tentu saja, Anda tidak dapat mencatat peristiwa bug karena jika Anda bisa, Anda tidak akan membuat bug sejak awal.

Salah satu ide untuk melacak bug adalah mencari jejak di database. Jejak ini memungkinkan kami untuk melihat bahwa ada bug dan mengirimkan peringatan. Bagaimana kita bisa membantu ini? Kami mulai menyelidiki setiap bug besar dan menghasilkan solusi: jenis pemantauan / peringatan SMS apa yang dapat dibuat untuk membuat bug ini langsung terungkap sebagai kesalahan 500? Berikut ini beberapa contohnya.

1.1. Contoh gangguan yang disebabkan oleh bug

Tiba-tiba kami menerima sejumlah besar keluhan dari pengguna kami: pesanan yang dibayarkan melalui Apple Pay tidak dapat ditutup. Kami memulai penyelidikan kami; masalahnya direproduksi di lingkungan uji. Akar penyebabnya ditemukan: kami memperbarui format tanggal kedaluwarsa untuk kartu kredit karena diubah oleh layanan pemrosesan pembayaran, tetapi kami tidak melakukannya dengan benar untuk pembayaran melalui Apple Pay; karena itu, semua pembayaran Apple Pay ditolak. Kami memperbaikinya segera setelah kami tahu tentang masalah tersebut, menyebarkannya dan masalahnya hilang. Namun, masalah ini hidup selama 45 menit.

Setelah masalah ini, kami memantau sejumlah pembayaran Apple Pay yang gagal dan membuat SMS dan peringatan IVR dengan beberapa ambang batas yang tidak nol (karena beberapa pembayaran yang gagal dianggap normal oleh layanan; misalnya, jika klien tidak memiliki uang di akunnya) atau kartu kreditnya diblokir). Sejak saat itu, kami segera mencari tahu tentang penyeberangan ambang batas. Jika rilis baru membawa masalah ke dalam pemrosesan Apple Pay, kami akan segera mengetahui hal itu karena memantau dan mengembalikannya dalam 3 menit (proses rollback manual dijelaskan dalam salah satu artikel sebelumnya). Jadi dulu 45 menit downtime parsial, dan sekarang 3 menit. Untung!

1.2. Contoh lainnya

Bug dalam daftar pesanan. Kami menerapkan optimalisasi daftar pesanan di aplikasi driver. Kode memiliki bug. Akibatnya, terkadang pengemudi melihat daftar pesanan kosong. Kami mengetahui tentang bug ini secara kebetulan: salah satu insinyur sedang bermain dengan aplikasi driver dan menemukan masalah ini. Kami dengan cepat mengidentifikasi rilis buruk dan segera diluncurkan kembali. Akibatnya, kami membuat grafik jumlah pesanan rata-rata dalam daftar berdasarkan info dari basis data. Kemudian kami melihat grafik ini secara retrospektif dari bulan ke bulan. Kami melihat jurang baru-baru ini yang disebabkan oleh bug itu dan membuat peringatan SMS melalui kueri SQL. Itu membangun grafik ini ketika jumlah rata-rata pesanan dalam daftar melewati ambang yang lebih rendah yang ditetapkan berdasarkan minimum untuk bulan berjalan.

Bug dalam cachback. Kami mengubah logika pemberian uang kembali pengguna. Antara lain, kami mengirimkannya ke grup klien yang salah. Masalahnya telah diperbaiki, grafik uang kembali yang diberikan telah dibuat; kami melihat peningkatan drastis di dalamnya dan juga memperhatikan bahwa ini belum pernah terjadi sebelumnya, dan menciptakan peringatan SMS dengan ambang batas yang sesuai.

Sekali lagi bug dalam pembayaran. Rilis baru menyebabkan bug - butuh selamanya untuk melakukan pemesanan, pembayaran kartu tidak bekerja, pengemudi meminta klien untuk membayar tunai. Kami menemukan masalah melalui keluhan call center. Kami mengerahkan perbaikan dan membuat peringatan untuk waktu penutupan untuk pesanan dengan ambang batas, ditemukan melalui analisis grafik historis.

Seperti yang Anda tahu, kami menggunakan pendekatan yang sama untuk menangani semua insiden semacam ini:

Kami mencari tahu tentang masalah.
Kami memecahkan masalah itu dan menemukan bug dalam kode.
Kami memperbaikinya.
Kami mencari jejak di basis data (juga jejak dapat ditemukan di log server web atau Kibana) yang dapat menunjukkan tanda-tanda masalah.
Kami membuat grafik jejak ini.
Kami kembali ke masa lalu dan melihat naik turunnya grafik.
Kami memilih ambang batas yang baik untuk lansiran.
Ketika masalah muncul lagi, kami segera mengetahuinya melalui peringatan SMS.

Apa yang baik tentang metode ini: satu grafik dan satu lansiran menyelesaikan seluruh kelompok besar masalah (contoh kelompok bermasalah: pesanan tidak dapat ditutup, bonus tambahan, pembayaran Apple Pay tidak melalui, dll.)

Akhirnya, kami menerapkan peringatan dan pemantauan untuk setiap bug besar sebagai bagian dari budaya rekayasa kami. Agar tidak kehilangan budaya ini, kami memformalkannya sedikit. Kami mulai memaksa diri untuk membuat laporan untuk setiap pemadaman. Laporan ini adalah formulir yang diisi dengan jawaban untuk pertanyaan-pertanyaan berikut: akar penyebab, bagaimana kami memperbaikinya, dampak bisnis, takeaways. Semua bidang wajib diisi. Jadi, kami harus menyimpulkan apakah kami menyukainya atau tidak. Perubahan proses ini jelas ditulis ke dalam Do's and Don't's.

2. Kotan

Tingkat otomatisasi proses kami meningkat, dan kami memutuskan bahwa sudah waktunya untuk membuat antarmuka web yang akan menunjukkan status proses pengembangan saat ini. Kami menyebut antarmuka web ini "Kotan" (dari kata Rusia "roll", "to roll out" :-)

"Kotan" memiliki fungsi berikut:

Daftar insiden . Ini berisi daftar semua yang dipicu dalam peringatan sebelumnya - yang mana membutuhkan reaksi manusia segera. Untuk setiap kejadian, kami mendaftarkan waktu dimulainya, waktu berakhir (jika sudah selesai), tautan ke laporan (jika insiden selesai dan ada laporan), dan tautan panduan lansiran untuk melihat jenis lansiran kejadian ini milik.

Direktori peringatan . Ini sebenarnya daftar semua peringatan. Untuk membuatnya lebih jelas, perbedaan antara peringatan dan insiden adalah sebagai berikut: lansiran seperti kelas, sedangkan insiden - adalah objek. Misalnya, "jumlah 500 kesalahan lebih besar dari 1" adalah peringatan. Dan "jumlah 500 kesalahan lebih besar dari 1 dan mereka terjadi pada tanggal ini, saat ini, berlangsung selama ini" - adalah sebuah insiden. Setiap peringatan ditambahkan ke sistem secara manual melalui proses yang dijelaskan di atas setelah beberapa masalah khusus yang belum pernah terdeteksi oleh sistem peringatan sebelum diselesaikan. Pendekatan berulang seperti itu menjamin risiko peringatan positif palsu yang rendah (yang tidak memerlukan tindakan). Direktori berisi riwayat laporan lengkap untuk setiap jenis lansiran; yang membantu mendiagnosis masalah lebih cepat: Anda menerima peringatan, Anda pergi ke "Kotan", klik pada Direktori, periksa semua sejarah dan dapatkan ide tentang tempat menyelam. Kunci untuk pemecahan masalah yang berhasil adalah memiliki semua informasi yang ada. Tautan ke kode sumber lansiran (untuk mengetahui dengan pasti situasi apa yang disiagakan oleh lansiran ini). Deskripsi tertulis tentang metode terbaik saat ini untuk memerangi peringatan ini.

Laporan Ini semua adalah laporan dalam sejarah. Setiap laporan memiliki tautan untuk semua insiden yang terkait (kadang-kadang insiden datang dalam kelompok; akar penyebabnya sama, dan kami membuat satu laporan untuk seluruh kelompok), tanggal laporan ini ditulis, bendera konfirmasi solusi masalah, dan sebagian besar penting: penyebab utama, bagaimana hal itu diperbaiki, berdampak pada bisnis, takeaways.

Daftar takeaways . Setiap takeaway memiliki catatan yang menyatakan apakah itu telah dilaksanakan, implementasi masih akan datang, atau tidak diperlukan (dengan penjelasan mengapa tidak).

3. Apa yang berubah dalam proses pengembangan perangkat lunak?

Komponen penting dari peningkatan ketersediaan adalah proses pengembangan perangkat lunak. Prosesnya terus berubah. Tujuan dari perubahan tersebut adalah mengurangi peluang terjadinya insiden. Keputusan untuk mengubah proses tidak harus dibuat secara abstrak, tetapi lebih didasarkan pada pengalaman, fakta dan angka. Proses tidak boleh dibangun secara langsung ke bawah, tetapi dari bawah ke atas dengan semua anggota tim berpartisipasi aktif, karena banyak kepala seluruh tim lebih baik daripada satu kepala manajer. Proses harus diikuti dan dipantau; jika tidak, tidak masuk akal untuk memilikinya. Anggota tim harus saling mengoreksi jika ada perbedaan: siapa lagi yang akan melakukannya untuk mereka? Harus ada otomatisasi maksimum untuk menjaga fungsi-fungsi utama, karena manusia membuat kesalahan terus-menerus, terutama pada pekerjaan kreatif.

Untuk memastikan bahwa setiap kejadian memiliki takeaways, kami telah melakukan hal berikut:

Setiap peringatan secara otomatis memblokir rilis.
Saat kami menerima peringatan penutupan (pesan teks yang menyatakan bahwa insiden telah berakhir), kami tidak segera membebaskan rilisnya, tetapi kami ditawari untuk membuat laporan tentang kecelakaan.
Laporan harus berisi informasi berikut: akar penyebab kecelakaan, cara memperbaikinya, dampak bisnis, takeaways.
Laporan ini ditulis oleh tim yang mengacaukan kecelakaan. Mereka yang dipersenjatai dengan informasi lengkap tentang kecelakaan itu.
Rilis secara otomatis diblokir sampai laporan tersebut dibuat dan disetujui. Itu memotivasi tim untuk cepat berkonsentrasi dan membuat laporan tepat setelah kecelakaan diperbaiki.
Laporan harus disetujui oleh seseorang yang tidak ada di tim, untuk memastikan bahwa laporan tersebut berisi semua informasi yang diperlukan untuk memahaminya.

Dengan melakukan itu, kami, di satu sisi, mencapai disiplin diri dalam menyelamatkan setiap kejadian dalam sejarah, dan di sisi lain - memberikan kontrol otomatis. Sekarang tidak mungkin untuk tidak menarik kesimpulan atau tidak menulis laporan.

4. Sebagai pengganti epilog

Sebagai pengganti epilog, izinkan saya dengan cepat merangkum apa yang kami ubah dalam proses pengembangan perangkat lunak untuk mengurangi sejumlah perjalanan yang hilang.

Apa yang kita ubah?	Mengapa kami mengubahnya?
Kami mulai menyimpan log kecelakaan.	Untuk memiliki takeaways dan mencegah kecelakaan di masa depan.
Kami membuat post-mortem untuk setiap pemadaman besar (yang dengan banyak perjalanan hilang).	Untuk mempelajari cara memecahkan masalah dengan cepat dan memperbaiki pemadaman di masa mendatang.
Kami membuat file Do dan Dont.	Untuk berbagi nugget kebijaksanaan dengan semua insinyur.
Hanya satu rilis per lima menit.	Untuk mengurangi durasi pemecahan masalah.
Pertama, kami menyebarkan kode pada satu server web prioritas rendah dan hanya pada saat itu - pada semua yang lain.	Untuk mengurangi dampak rilis yang buruk.
Rollback rilis buruk otomatis.	Untuk mengurangi dampak rilis yang buruk.
Tidak ada penyebaran selama pemadaman.	Untuk mempercepat pemecahan masalah.
Kami menulis tentang rilis dan kecelakaan di obrolan grup.	Untuk mempercepat pemecahan masalah.
Kami memantau grafik selama 3 menit setelah setiap rilis.	Untuk mempercepat pemecahan masalah.
Peringatan SMS dan IVR tentang masalah.	Untuk mempercepat pemecahan masalah.
Setiap bug (terutama yang besar) diikuti dengan melakukan pemantauan dan peringatan.	Untuk mempercepat pemecahan masalah situasi serupa di masa mendatang.
Ulasan optimasi kode.	Untuk mengurangi kemungkinan kecelakaan karena kelebihan basis data.
Optimasi kode reguler (dengan MySQL slow.log sebagai input).	Untuk mengurangi sejumlah kecelakaan karena "telur Paskah".
Setiap kecelakaan pasti memiliki takeaway.	Ini mengurangi kemungkinan kecelakaan semacam itu di masa depan.
Setiap kecelakaan harus memiliki peringatan.	Ini mengurangi durasi pemecahan masalah dan perbaikan untuk kecelakaan semacam itu di masa depan.
Pemblokiran otomatis rilis baru setelah kecelakaan sebelum laporan ditulis dan disetujui.	Ini meningkatkan kemungkinan memiliki takeaways yang tepat, sehingga mengurangi kemungkinan kecelakaan seperti itu di masa depan.
"Kotan" - alat peningkatan layanan otomatis.	Ini mengurangi durasi pemadaman; mengurangi kemungkinan terjadinya pemadaman.
Direktori insiden.	Ini mengurangi durasi pemecahan masalah

Terima kasih sudah membaca sampai akhir. Semoga sukses untuk bisnis Anda! Saya harap Anda tidak kehilangan pesanan, transaksi, pembelian, perjalanan, dan apa pun yang penting bagi Anda!