Dengan artikel ini, saya membuka siklus pendek dari dua artikel di mana saya akan menjelaskan secara rinci bagaimana kami berhasil meningkatkan stabilitas layanan Citymobil beberapa kali selama beberapa bulan. Artikel dimulai dengan cerita tentang bisnis kita, tentang tugas, tentang alasan munculnya masalah peningkatan stabilitas dan tentang keterbatasan. Citymobil adalah agregator taksi yang tumbuh cepat. Pada 2018, itu tumbuh lebih dari 15 kali dalam jumlah perjalanan yang sukses. Dalam beberapa bulan, pertumbuhan melebihi 50% dibandingkan bulan sebelumnya.
Bisnis tumbuh dengan pesat (dan masih terus berkembang): beban di server, ukuran tim, dan frekuensi peluncuran telah meningkat. Bersamaan dengan ini, ancaman baru terhadap stabilitas layanan muncul. Perusahaan menghadapi tugas yang paling penting - tidak menghentikan pertumbuhan bisnis untuk meningkatkan stabilitas. Dalam artikel ini saya akan memberi tahu Anda bagaimana kami berhasil mewujudkan tugas ini dalam waktu singkat.
1. Pernyataan masalah: apa sebenarnya yang ingin kita tingkatkan
Sebelum Anda meningkatkan sesuatu, Anda perlu belajar bagaimana mengukurnya agar dapat memahami dengan jelas jika ada peningkatan. Semakin dekat nilai yang diukur dengan istilah ramah bisnis, semakin baik. Karena semakin besar kemungkinan kita akan meningkatkan apa yang benar-benar dibutuhkan bisnis. Dari sudut pandang keberhasilannya, parameter terpenting bagi kami adalah jumlah perjalanan yang berhasil diselesaikan (selanjutnya secara singkat - jumlah perjalanan). Justru dengan parameter ini investor menilai kami ketika mereka membuat keputusan tentang investasi. Semakin banyak perjalanan, semakin mahal perusahaan itu.
Beberapa perjalanan menghasilkan untung, sebagian - rugi. Tetapi semua perjalanan sama pentingnya bagi kami, bahkan tidak menguntungkan, karena mereka memungkinkan Anda untuk meningkatkan pangsa pasar (pada kenyataannya, kerugian perjalanan adalah pembayaran untuk meningkatkan pangsa pasar). Karena itu, setiap perjalanan tambahan yang diterima baik, dan setiap perjalanan yang hilang buruk. Semua perjalanan adalah sama dalam hal keberhasilan bisnis.
Dari sini kami mendapat kriteria yang dapat dipahami untuk mengukur stabilitas: jumlah perjalanan yang hilang adalah perjalanan yang jelas-jelas hilang karena masalah teknis. Masalah teknis berarti, misalnya, bug dalam kode, kesalahan ke-500, kerusakan infrastruktur, rusaknya integrasi dengan layanan mitra (misalnya, Google maps).
2. Bagaimana cara menghitung perjalanan yang hilang?
Perjalanan yang hilang terkadang mudah dihitung, terkadang sulit. Misalnya, dalam kasus penolakan layanan lengkap, ketika tidak ada yang bekerja sama sekali (pah-pah-pah), sangat mudah untuk menghitung perjalanan yang hilang. Kita tahu grafik tren jumlah perjalanan sebelum musim gugur, kita melihat tren grafik ini setelah musim gugur, kita menyelesaikan garis antara titik ketika mulai sederhana dan titik saat berakhir. Area grafik jumlah perjalanan di bawah garis yang diselesaikan ini adalah perjalanan yang hilang.
Dalam grafik berikut, garis hitam menunjukkan perjalanan pada hari tertentu dan garis hijau menunjukkan perjalanan seminggu yang lalu. Sumbu X adalah waktu. Pada sumbu Y, jumlah perjalanan dalam interval waktu tertentu di sekitar titik X. Puncak yang jelas terlihat dalam bentuk segitiga siku akut. Luas segitiga ini adalah jumlah perjalanan yang hilang. Tentu saja, ini merupakan jumlah perkiraan, karena grafik berfluktuasi, tetapi kami memahami bahwa akurasi 10-20% saja sudah cukup bagi kami untuk memperkirakan skala kecelakaan untuk suatu bisnis.
Jika sederhana tidak lengkap, tetapi parsial (juga, pah-pah-pah), maka perhitungannya sedikit lebih rumit. Misalnya, jika ada bug karena 10% pesanan tidak pernah didistribusikan oleh mobil, maka kami melihat kegagalan pada jadwal perjalanan, dan kemudian rebound (setelah memperbaiki bug). Dalam situasi yang sama, perjalanan yang hilang adalah area yang dibatasi di atas oleh garis tren; dari bawah - jadwal aktual dari jumlah perjalanan, ke kiri - garis vertikal dari awal downtime, ke kanan - garis vertikal akhir downtime.
Grafik di bawah ini menunjukkan bahwa puncak turun tidak begitu jelas, tetapi kehadiran perjalanan untuk minggu sebelumnya tanpa puncak turun membantu untuk memahami bahwa puncak turun adalah kerugian. Selain itu, perbandingan perjalanan untuk hari ini dan hari yang sama dari minggu ke minggu sebelumnya memperjelas bahwa puncak paling kanan bukanlah perjalanan yang hilang, tetapi merupakan kegagalan yang biasa terjadi pada saat itu, karena itu berkorelasi dengan minggu sebelumnya.
Biasanya sulit untuk membangun garis tren, karena grafik gigi gergaji. Dalam hal ini, perbandingan dari minggu ke minggu membantu kita. Jika Anda menggambar dua garis pada grafik yang sama - minggu terakhir dan yang sekarang - maka ternyata kurva plus atau minus keduanya memiliki bentuk yang sama, tetapi hanya berbeda satu di atas yang lain (minggu saat ini biasanya lebih tinggi dari yang sebelumnya, meskipun ada pengecualian). Perbandingan minggu ke minggu adalah penting, karena setiap hari dalam seminggu, karena keadaan yang berbeda, memiliki bentuk jadwal yang berbeda. Melihat grafik minggu-ke-minggu, Anda bisa memahami di mana garis tren perjalanan hari ini.
Jelas, perjalanan yang hilang itu sendiri adalah masalah yang jauh lebih besar daripada hanya satu perjalanan yang hilang. Seorang klien yang ingin pergi dengan satu atau lain cara akan pergi, misalnya, menggunakan layanan yang kompetitif dan selanjutnya tidak dapat kembali kepada kami, atau kembali hanya ketika pesaing mengecewakannya, yang tidak mungkin, karena Pesaingnya sangat kuat. Selain itu, bahkan jika pesaing mengecewakan klien, maka klien bukan fakta bahwa ia akan kembali, karena semuanya akan terlihat di kepalanya sehingga semua orang memiliki layanan yang buruk, dan tidak ada gunanya melompati pesaing.
Artinya, satu perjalanan yang hilang karena masalah teknis berarti, pada kenyataannya, beberapa perjalanan yang hilang.
Agar tidak bingung dalam hal, kami menyebut perjalanan yang hilang secara langsung karena masalah teknis,
perjalanan yang hilang primer , dan perjalanan yang hilang karena meninggalkan pesaing,
perjalanan yang hilang sekunder .
Idealnya, untuk menghitung total kerusakan bisnis dari satu perjalanan yang hilang primer, Anda perlu memahami berapa banyak yang dihasilkan dari perjalanan yang hilang sekunder. Yaitu perlu untuk melipatgandakan jumlah perjalanan awal yang hilang dengan koefisien
K tertentu, yang dapat dihitung berdasarkan frekuensi rata-rata menggunakan layanan dan waktu rata-rata untuk mengembalikan pengguna setelah meninggalkan pesaing.
Di bawah asumsi bahwa koefisien
K tidak banyak berubah dari waktu ke waktu, untuk memahami tren kehilangan perjalanan, cukuplah untuk mempertimbangkan perjalanan yang hilang primer dan berusaha untuk mengurangi jumlahnya, karena rasio perjalanan yang hilang primer periode-ke-periode akan sama dengan rasio perjalanan yang hilang sekunder periode-ke-periode periode. Contoh: jika kami kehilangan 1000 perjalanan utama bulan lalu, maka perjalanan sekunder kami kehilangan 1000 *
K , dan totalnya kami kehilangan 1000 * (1+
K ). Jika, lebih lanjut, pada bulan ini kami kehilangan 500 perjalanan primer, maka perjalanan sekunder kami kehilangan 500 *
K , dan total kami kehilangan 500 * (1+
K ). Dalam hal ini, terlepas dari nilai koefisien
K, kami mulai kehilangan perjalanan 1000 * (1+
K ) / (500 * (1+
K )) = 2 kali lebih sedikit.
Bahkan jika koefisien
K berubah seiring waktu, mis. adalah fungsi dari waktu K (t), maka kami masih tertarik untuk mengurangi jumlah perjalanan yang hilang primer. Karena jika K (t) tumbuh seiring waktu, maka kita semua lebih wajib melakukan upaya untuk kehilangan lebih sedikit perjalanan primer, karena kerusakan karena kehilangan masing-masing lebih tinggi dan lebih tinggi. Di sisi lain, jika K (t) menurun dari waktu ke waktu, maka ini berarti bahwa untuk beberapa alasan, pengguna lebih dan lebih setia kepada kami, meskipun layanannya buruk, yang berarti kami harus memenuhi harapan mereka!
Total: kami berjuang untuk penurunan konstan dalam perjalanan primer yang hilang.
3. Oke, kami mempertimbangkan perjalanan yang hilang. Apa selanjutnya
Berbekal alat yang dapat dipahami untuk mengukur perjalanan yang hilang, kita beralih ke bagian yang paling menarik - bagaimana melakukannya untuk mengurangi kerugian? Dan sementara tidak memperlambat pertumbuhan saat ini! Karena secara subyektif nampak bagi kami bahwa bagian terbesar dari masalah teknis yang menyebabkan perjalanan hilang terkait dengan backend, kami memutuskan untuk pertama-tama memperhatikan proses pengembangan backend. Ke depan, saya akan mengatakan bahwa ternyata seperti itu - backend telah menjadi medan perang utama untuk perjalanan yang hilang.
4. Bagaimana prosesnya bekerja
Masalah biasanya terjadi karena pengguliran kode dan tindakan manual lainnya. Layanan yang tidak pernah berubah dan tidak pernah menyentuh, terkadang juga gagal, tetapi pengecualian ini hanya aturan konfirmasi.
Pengecualian terlucu dalam pengalaman saya adalah layanan berikut. Ketika saya bekerja di RBC pada tahun 2006 (Ya Tuhan, berapa usia saya!), Kemudian di salah satu layanan surat RBC ada gateway tempat semua lalu lintas berlalu dan yang memeriksa alamat IP untuk dimasukkan daftar hitam. Layanan bekerja pada FreeBSD, dan berfungsi dengan baik. Tetapi suatu hari, dia berhenti bekerja. Tebak kenapa? Disk hancur pada mesin ini (blok buruk terakumulasi, terakumulasi dan terakumulasi). Hancur 3 tahun sebelum penolakan layanan dalam layanan (!). Dan semuanya hidup dengan disk yang tersebar. Dan kemudian "frach", untuk alasan apa pun yang tidak diketahui olehnya oleh motif Phryakhov, memutuskan untuk tiba-tiba beralih ke disk yang hancur dan akhirnya membeku. Saya yakin Linux tidak akan melakukan itu. Tetapi ini adalah holivar yang terpisah.
Untuk meringkas di atas, masalahnya adalah karena intervensi manual. Sekali di masa kecil saya, pada usia 10-12, di salah satu perjalanan saya ke hutan, saya mendengar dari ayah saya ungkapan yang saya ingat seumur hidup: "agar api unggun tidak padam, Anda tidak perlu menyentuhnya." Saya pikir banyak dari kita yang ingat saat-saat ketika kita melemparkan kayu bakar ke dalam api yang sudah menyala dan padam karena alasan yang tidak diketahui.
Intinya: masalah diciptakan oleh tindakan manual seseorang, misalnya, melemparkan kayu bakar ke api yang sudah menyala dengan baik, yang memotong oksigen dan memadamkan api, atau dengan mengeluarkan kode dengan bug dalam produksi. Oleh karena itu, untuk memahami penyebab masalah dalam layanan, Anda harus memahami dengan tepat bagaimana roll-out terjadi dan bagaimana proses pengembangan bekerja.
Proses ini sepenuhnya berfokus pada perkembangan cepat dan diorganisasikan sebagai berikut:
- 20-30 rilis per hari;
- pengembang meluncurkan sendiri;
- pengujian cepat dalam lingkungan pengujian oleh pengembang;
- uji unit / otomatis minimum, ulasan minimum.
Pengembang dalam kondisi yang paling sulit, pada kenyataannya, tanpa area belakang yang tertutup dalam menghadapi QA, dengan aliran besar tugas-tugas produktif dan eksperimen yang penting untuk bisnis, bekerja dengan fokus dan terkoordinasi mungkin, menyelesaikan masalah kompleks dengan cara sederhana, tidak membiarkan kode untuk "tumbuh", masalah bisnis yang dipahami dengan baik , sangat bertanggung jawab terhadap perubahan, dengan cepat memutar kembali idle. Citymobil tidak unik di sini. 8 tahun yang lalu di Mail.ru Mail, ketika saya datang untuk bekerja di sana, ada situasi yang sama. Dan kami juga memulai Cloud Mail.ru dengan cepat dan sederhana, tanpa curtsy. Dan selanjutnya telah mengubah proses untuk mencapai stabilitas yang lebih besar.
Tentunya, Anda memperhatikan hal ini sendiri: ketika tidak ada yang menutupi punggung Anda, ketika hanya Anda yang sendirian dengan produksi, ketika beban tanggung jawab yang besar meremukkan - Anda melakukan keajaiban. Saya sendiri punya pengalaman seperti itu (bahkan lebih hardcore). Suatu ketika, pada abad terakhir (perkiraan, Internet sudah ada di abad terakhir, saya terkejut ketika saya ingat), saya bekerja sebagai satu-satunya pengembang layanan surat newmail.ru, menyebarkannya sendiri, dan juga menguji produksi sendiri untuk diri Anda sendiri melalui
if (!strcmp(username, “danikin”)) { … some new code… } :-) Oleh karena itu, situasi ini dekat dengan saya.
Saya tidak terkejut jika saya tahu bahwa dengan pendekatan yang sederhana "di atas lutut" banyak perusahaan baru mulai, baik yang berhasil maupun yang tidak berhasil, tetapi didorong oleh hasrat yang sama - fokus pada pertumbuhan bisnis yang cepat dan tangkapan pasar.
Mengapa prosesnya khusus di Citymobil? Awalnya, ada beberapa pengembang. Mereka bekerja di perusahaan untuk waktu yang lama dan memiliki pemahaman yang baik tentang kode dan bisnis. Peluncuran beberapa kali sehari. Kesalahan sangat jarang terjadi. Prosesnya bekerja dengan sempurna untuk kondisi tersebut.
5. Mengapa proses yang baik mengancam stabilitas?
Dengan meningkatnya investasi dalam proyek, kami membuat rencana produk kami lebih agresif dan mulai mempekerjakan banyak pengembang. Jumlah peluncuran pada produksi meningkat, tetapi kualitas mereka diperkirakan akan turun, karena orang-orang baru menggali ke dalam sistem dan esensi bisnis yang tepat dalam kondisi pertempuran. Dengan peningkatan jumlah pengembang, stabilitas mulai turun bahkan tidak secara linier, tetapi secara kuadrat (jumlah peluncuran meningkat secara linear, dan kualitas peluncuran rata-rata juga turun secara linear; "linear" * "linearly" == "quadratically").
Jelas bahwa tidak mungkin meninggalkan proses dalam bentuk ini. Itu sama sekali tidak dipenjara dalam kondisi baru. Tapi itu perlu untuk mengubahnya tanpa mengurangi waktu-ke-pasar, yaitu, dengan pelestarian 20-30 rilis per hari (dan dengan peningkatan jumlah mereka sebanding dengan ukuran tim). Memang, dalam sejumlah besar rilis itulah intinya dibuat. Kami tumbuh dengan cepat, membuat banyak percobaan, dengan cepat mengevaluasi hasil mereka dan membuat eksperimen baru. Kami dengan cepat menguji hipotesis produk dan bisnis, mempelajarinya dan mengajukan hipotesis baru, yang kami uji lagi dengan cepat, dll. Kami tidak ingin mengurangi tingkat ini dalam hal apa pun. Selain itu, mereka ingin meningkatkannya, dan meningkatkan kecepatan mempekerjakan pengembang. Yaitu tindakan kami yang ditujukan untuk pertumbuhan bisnis menciptakan ancaman bagi stabilitas, tetapi kami tidak ingin memperbaiki tindakan ini dengan cara apa pun.
6. Ok, tugasnya jelas, prosesnya jelas. Apa selanjutnya
Memiliki pengalaman di Mail.ru Cloud dan Mail.ru Cloud, di mana stabilitas dari beberapa titik ditempatkan di garis depan, di mana peluncuran sekali seminggu, dijelaskan dalam fungsionalitas detail dan kasus uji, semuanya ditutupi dengan tes otomatis dan unit, kode ditinjau setidaknya sekali, dan kadang-kadang tiga kali, saya menemukan situasi yang sama sekali baru.
Tampaknya semuanya sederhana: ulangi proses di Citymobil seperti di Mail atau Cloud dan tingkatkan stabilitas layanan. Tetapi, seperti dalam lelucon cabul itu, ada nuansa: a) peluncuran di Mail / Cloud dilakukan seminggu sekali, dan tidak 30 kali sehari, dan di Citymobil kami tidak ingin mengorbankan frekuensi rilis, b) di Mail / Cloud semua kode dicakup oleh uji unit otomatis, dan dalam Citymobil kami tidak punya waktu dan sumber daya untuk ini, semua kekuatan pengembangan backend dikhususkan untuk menguji hipotesis dan peningkatan produk. Pada saat yang sama, tidak ada cukup banyak pengembang backend, bahkan pada kecepatan perekrutan yang tinggi (terima kasih khusus kepada HR Citymobil - ini adalah SDM terbaik di dunia! Saya pikir akan ada artikel terpisah tentang proses SDM kami), yaitu, tidak ada cara untuk terlibat dalam tes dan ulasan yang ketat tanpa melambat.
7. Ketika Anda tidak tahu harus berbuat apa, maka belajarlah dari kesalahan
Jadi apa yang telah kami lakukan secara ajaib di Citymobil? Kami memutuskan untuk belajar dari kesalahan. Metode meningkatkan layanan melalui belajar dari kesalahan sama tuanya dengan dunia. Jika sistem berfungsi dengan baik, maka itu bagus. Jika sistem berfungsi dengan kesalahan, maka ini juga bagus, karena Anda dapat belajar dari kesalahan ini. Kedengarannya mudah. Untuk melakukan ... juga sederhana. Yang utama adalah menetapkan tujuan.
Bagaimana cara kita belajar? Kami mulai dengan secara cermat merekam informasi tentang setiap kecelakaan besar dan kecil. Terus terang, saya awalnya tidak benar-benar ingin melakukan ini, karena saya berharap untuk keajaiban dan berpikir bahwa kecelakaan akan berhenti sendiri. Tentu saja, tidak ada yang berhenti. Realitas baru dengan kejam menuntut perubahan.
Kami mulai mencatat semua kecelakaan di tabel umum Google. Untuk setiap kecelakaan, informasi singkat berikut diberikan:
- tanggal, waktu, durasi;
- akar permasalahan
- apa yang mereka lakukan untuk menyelesaikan masalah;
- dampak pada bisnis (jumlah perjalanan yang hilang, efek lainnya);
- kesimpulan.
Untuk kecelakaan besar, kami membuat file besar yang terpisah dengan deskripsi menit demi menit yang terperinci, mulai dari saat kecelakaan dimulai hingga saat penyelesaian: apa yang kami lakukan, keputusan apa yang kami buat (biasanya deskripsi seperti itu disebut analisis post-mortem). Dan pada tabel umum kami menambahkan tautan ke post-mortem tersebut.
Tujuan dari file ini adalah satu: untuk menarik kesimpulan, implementasi yang akan mengurangi kerugian perjalanan. Selain itu, sangat penting untuk merumuskan secara akurat apa “akar penyebab” itu dan apa “kesimpulannya”. Kata-kata ini bisa dimengerti dalam diri mereka sendiri. Tapi semua orang mengerti dengan caranya sendiri.
8. Contoh kesalahan yang mereka pelajari
Akar penyebabnya adalah penghapusan yang akan mencegah kecelakaan serupa di masa depan. Dan kesimpulannya adalah bagaimana menghilangkan akar penyebab (atau mengurangi kemungkinan terjadinya akar).
Akar penyebabnya selalu lebih dalam dari yang terlihat. Kesimpulan selalu lebih rumit dari yang terlihat. Agar tidak tenang dan memikirkan apa yang tampaknya, orang harus selalu tidak puas dengan akar penyebab yang seharusnya ditemukan dan selalu tidak puas dengan kesimpulan yang diduga. Ketidakpuasan ini menciptakan semangat untuk analisis lebih lanjut.
Biarkan saya memberi Anda sebuah contoh: meluncurkan kode - semuanya jatuh, bergulir kembali - semuanya bekerja. Apa akar masalahnya?
Roll out , katamu. Jika dia tidak ada, tidak akan ada kecelakaan. Jadi apa kesimpulannya: jangan roll out? Kesimpulan buruk (berbahaya bagi bisnis, tepatnya). Artinya, ini kemungkinan besar bukan akar penyebabnya, Anda perlu menggali lebih dalam.
Gulirkan dengan bug . Penyebab dasarnya? Katakan saja. Bagaimana cara memperbaikinya? Dengan tes, katamu. Tes apa? Misalnya, regresi lengkap semua fungsi. Ini kesimpulan yang bagus, ingat itu. Tetapi stabilitas harus ditingkatkan di sini dan sekarang, sementara tidak ada regresi lengkap. Perlu menggali lebih dalam.
Peluncuran dengan bug yang terjadi karena fakta bahwa kami melakukan debug pencetakan di tabel dalam database, memuatnya di luar ukuran dan database rusak karena beban . Ini sudah lebih menarik. Segera menjadi jelas bahwa bahkan uji regresi lengkap tidak akan menyelamatkan Anda dari masalah ini. Lagi pula, basis uji tidak akan memiliki beban yang sama dengan produksi.
Apa akar penyebab masalah ini, jika Anda menggali lebih dalam? Untuk mengetahuinya, kami berbicara dengan pengembang. Ternyata dia terbiasa dengan fakta bahwa pangkalan itu mengatasi beban. Tetapi dalam kondisi pesatnya pertumbuhan proyek, pangkalan dikelola kemarin, tetapi hari ini tidak ada lagi. Beberapa dari kita telah mengerjakan proyek yang tumbuh sebesar 50% dari bulan ke bulan. Sebagai contoh, bagi saya ini adalah proyek pertama. Setelah terjun ke proyek semacam itu, Anda mulai menyadari kenyataan baru. Sampai pertama kali Anda menemukan sesuatu, Anda tidak akan pernah tahu apa yang terjadi.
Pengembang segera menyarankan solusi yang tepat untuk penyebab kejatuhan: lakukan debug pencetakan dalam file, tulis file offline dengan cron ke database dalam satu aliran dengan slip. Jika ada terlalu banyak pencetakan debug, maka basis data tidak akan berbaring, hanya informasi debug yang akan muncul di luar waktu. Jelas, pengembang ini telah belajar dari kesalahannya dan tidak akan mengulanginya di masa depan. Tetapi pengembang lain juga perlu mencari tahu tentang hal ini. Bagaimana? Perlu memberi tahu mereka. Bagaimana cara membuatnya terdengar? Ceritakan kepada mereka keseluruhan cerita dari awal hingga akhir, jelaskan apa yang menyebabkannya dan segera sarankan cara melakukannya, serta dengarkan pertanyaan mereka dan jawab mereka.
9. Apa lagi yang bisa Anda pelajari dari kesalahan ini, atau lakukan & jangan
Jadi, kami terus menganalisis kecelakaan ini. Perusahaan ini berkembang pesat, karyawan baru datang. Bagaimana mereka akan belajar dari kesalahan ini? Beri tahu setiap karyawan baru? Jelas, akan ada semakin banyak kesalahan - bagaimana membuat semua orang belajar darinya? Jawabannya hampir jelas: dapatkan file do's & don'ts (baca “doos and donts”)! Dalam terjemahan bebas ke dalam bahasa Rusia, idiom do's & Don'ts berarti "apa yang baik dan apa yang buruk." Dalam file ini kami menulis semua kesimpulan tentang topik pengembangan. Kami menunjukkan file tersebut kepada semua karyawan baru, dan juga menunjukkannya di obrolan umum para pengembang setiap kali file diperbarui, dan kami dengan hormat meminta semua orang untuk membacanya lagi (untuk menyegarkan kembali pengetahuan lama dan baru).
Anda akan mengatakan bahwa tidak semua orang akan membaca dengan cermat. Anda akan mengatakan bahwa banyak orang akan segera lupa setelah membaca. Dan Anda akan benar dua kali. Tetapi Anda tidak akan menyangkal bahwa seseorang akan memiliki sesuatu di kepala mereka. Dan ini sudah bagus. Menurut pengalaman Citymobil, para pengembang menangani file ini dengan sangat serius, dan kasus-kasus ketika beberapa pelajaran dilupakan sangat jarang. Ngomong-ngomong, fakta bahwa pelajaran itu dilupakan dapat dianggap sebagai masalah dan kesimpulan dapat diambil darinya, yaitu, untuk memahami rinciannya dan memahami bagaimana mengubah proses untuk masa depan. Sangat sering, penggalian seperti itu mengarah pada kata-kata yang harus dilakukan dan tidak boleh dilakukan lebih akurat dan jelas.
Kesimpulan dari kecelakaan yang dijelaskan di atas: buat file yang harus dilakukan dan tidak boleh dilakukan, tulis apa yang telah Anda pelajari, tunjukkan file tersebut ke seluruh tim dan minta semua pendatang baru untuk mempelajarinya.
Dari saran umum yang kami pahami dalam analisis kecelakaan: jangan gunakan frasa "faktor manusia". Begitu Anda mengatakan ini, mereka semua segera memahaminya sehingga tidak perlu dilakukan, kesimpulan tidak diperlukan, orang salah, salah dan akan salah. Karena itu, alih-alih mengucapkan frasa ini, Anda perlu menarik
kesimpulan khusus . Kesimpulan - ini setidaknya merupakan langkah kecil, tetapi sedikit dalam mengubah proses, meningkatkan pemantauan, meningkatkan alat otomatis. Dari langkah sekecil itu, jalinan layanan stabil dijahit!
10. Alih-alih sebuah epilog
Pada bagian
kedua, saya akan memberi tahu Anda tentang jenis kecelakaan sesuai dengan pengalaman Citymobil dan menyelami rincian setiap jenis kecelakaan, dan juga memberi tahu Anda kesimpulan apa yang kami buat dari kecelakaan, bagaimana kami mengubah proses, yang memperkenalkan otomatisasi. Yang paling menarik di bagian kedua! Tetap disini!