Ketika merancang sistem IoT, misalnya, berbagi mobil, sangat penting untuk mempertimbangkan kemungkinan kegagalan. Jika tidak, Anda akan menemukan beban kritis pada dukungan teknis dan ketidakpuasan pelanggan.
Parkir "Skolkovskaya"Kegagalan terjadi di mana-mana. Tetapi di dunia "Internet of things" ini adalah keadaan permanen. Ketika bekerja dengan jaringan seluler dan perangkat keras, crash terjadi jauh lebih sering daripada di web atau pengembangan seluler.
Keandalan sistem menderita karena berbagai alasan, termasuk tenggat waktu yang ketat dan anggaran pengembangan yang terbatas. Tetapi IoT dapat bekerja jika kegagalan yang mungkin terjadi tidak ditolak, tetapi diterima dan cobalah untuk menyelesaikan masalah. Jika tertarik, ada
artikel yang menarik tentang metode untuk meningkatkan toleransi kesalahan, tetapi sekarang sudah mendekati intinya.
Anda membuka mobil dari telepon, apa yang salah?
Langkah-langkahnya mungkin tergantung pada arsitektur sistem, tetapi skenario umumnya seperti ini:
Anda mengklik tombol "Pesan Sekarang". Perintah dikirim ke server. Dia mungkin atau mungkin tidak berjalan.
Anda mengklik tombol "Buka mobil". Perintah dikirim ke server. Dia mungkin atau mungkin tidak berjalan. Server mengirimkan perintah ke mesin. Dia mungkin atau mungkin tidak berjalan. Perangkat terpasang mencoba menjalankan perintah. Mungkin terpenuhi atau tidak.
Anda mengklik tombol "Mulai Perjalanan". Perintah dikirim ke server. Dia mungkin atau mungkin tidak berjalan. Server mengirimkan perintah ke mesin. Dia mungkin atau mungkin tidak berjalan. Perangkat terpasang mencoba menjalankan perintah. Mungkin terpenuhi atau tidak.
Ya, ini adalah masalah dangkal dan sebenarnya jumlah yang gila, tetapi sekarang kita akan mempertimbangkan hanya ini.
Misalkan semua tim telah mencapai dan semua aktuator telah bekerja - sukses! Itu bisa ditunjukkan kepada investor.
Ada yang salah
Tetapi apa yang terjadi jika, misalnya, perintah "Pintu Terbuka" tidak mencapai mobil?
Pertama, server harus mencari tahu tentang hal ini. Agar keadaan sebenarnya dari mesin disinkronkan dengan server, biasanya digunakan perintah pengakuan (ACK). Dan konfirmasi lain dari eksekusi tim. Bagaimanapun, "tim belum dikirim" dan "tim belum dieksekusi" adalah peristiwa yang berbeda dan melibatkan berbagai upaya untuk menyelesaikannya.
Kedua, (jika masalah tidak dapat dipecahkan, misalnya, dengan mengirim ulang perintah), Anda harus melaporkan kesalahan kepada pengguna dan tidak memasukkannya ke status "trip".
Di Delimobile Anda akan memulai perjalanan.
Dan percakapan dengan operator dukungan teknis.
Ceritanya
Saya bekerja di Skolkovo. Karena kesulitan dengan aksesibilitas transportasi, seperti banyak rekan, saya pergi bekerja dan kembali setiap hari untuk berbagi mobil. Tapi 3 hari yang lalu, di zona parkir, koneksi memburuk. Mengapa ada masalah dengan komunikasi seluler di Pusat Inovasi adalah pertanyaan lain, tetapi situasi ini memunculkan masalah yang menarik: pengguna Delimobile yang memesan mobil sebenarnya terjebak.
Pada malam yang dingin tanggal 24 September, saya kembali ke rumah. Dia memesan mobil dan mendatanginya.
Mengklik "Mulai inspeksi", tetapi pintu tidak terbuka.
- Yah, mungkin, sekali lagi, kegagalan komunikasi. Saya akan mengambil satu lagi. Apalagi ada banyak sekali!
Mengklik "Selesai sewa" - "Anda keluar dari zona parkir"
Saya memanggil dukungan, menggambarkan situasinya. Operator sedang mencoba membuka pintu. Kegagalan. Musiknya. Pintu terbuka. Terima kasih
- Mungkin server gagal. Oke, ayo pergi. Saya menekan "Mulai perjalanan" - aplikasi mulai menghitung uang.
Tidak mulai.
Saya memanggil dukungan, menggambarkan situasinya. Operator sedang mencoba untuk menghidupkan mesin. Kegagalan. "Tidak ada koneksi dengan mesin."
- Oke, mari kita tutup secara manual. Turunkan gelas, keluar, tekan tombol kunci sentral, tutup kaca.
Gelas tidak jatuh. Ternyata, tanpa perintah dari server, mobil tidak menyalakan kunci kontak. Tetapi tidak ada koneksi.
- Maka Anda perlu menunggu mekanik. 1-1,5 jam.
"Tapi di sini dingin." Ada 3-4 lebih banyak orang di sekitar mobil Delimobile dengan telepon pergi. Mungkin bulu sudah dikirim kepada mereka ...
<Pintu mobil tiba-tiba ditutup>
- Ah, itu dia. Terima kasih Saya akan naik minibus.
Bagaimana orang lain mengatasi masalah ini
Pertama, jika tidak ada komunikasi dengan mesin, mungkin tidak boleh ditampilkan di peta.
Kedua, jika server tahu bahwa perintah untuk membuka pintu belum dieksekusi, itu tidak akan memindahkan saya ke mode rental. Jadi alih-alih 40 menit dalam dingin dan beban tambahan pada dukungan teknis, saya hanya akan melihat pesan kesalahan.
Ketiga, Anda dapat membuat saluran komunikasi cadangan - modem kedua dengan operator lain (saya punya Internet di telepon). Atau Bluetooth, seperti yang dilakukan di Squirrel dan YouDrive. (Mungkin opsi ini bukan untuk Delimobile, karena akan meningkatkan biaya pengembangan dan dukungan, dan DM adalah yang termurah di antara massa)
Sementara itu, Delimobil menyimpan mobil "ditutup secara manual" dan memuat dukungan teknisnya karena kurangnya konfirmasi pengiriman tim kontrol. Pada saat yang sama, mobil tanpa komunikasi terlihat di peta dan tersedia untuk dipesan.
Ini masalah yang lebih luas.
Saya yakin para insinyur Delimobile hebat. Mereka memecahkan banyak masalah. Serius. Memang, selain peralatan dan sistem itu sendiri, masih perlu untuk membangun proses commissioning, pemeliharaan, dekomisioning, dll. Seringkali, proses ini juga membutuhkan pengembangan perangkat keras dan perangkat lunak.
Tetapi mengapa kemudian situasi seperti itu muncul? Menurut pendapat saya, ada dua kemungkinan alasan.
Masalah yang mungkin pertama adalah kontraktor yang berbeda untuk aplikasi, server dan peralatan tanpa desain tingkat atas berkualitas tinggi dari keseluruhan sistem. Semua orang mungkin telah melakukan pekerjaannya dengan baik, tetapi arsitektur secara keseluruhan memiliki masalah.
Alasan kemungkinan kedua melekat pada begitu banyak proyek pada prinsipnya. Faktanya adalah bahwa untuk menunjukkan (misalnya, kepada investor) tidaklah sulit untuk membuat prototipe. Mungkin ini akan cukup untuk beberapa minggu atau bahkan berhari-hari. Namun, desain dan pengembangan sistem yang andal mungkin membutuhkan waktu sebulan, atau bahkan bertahun-tahun. Sayangnya, tidak semua manajer yang efektif memahami hal ini.
Seringkali, kepemimpinan yang efektif mungkin memerlukan fitur baru yang mereka yakini akan meningkatkan pendapatan perusahaan. Pada saat yang sama, mereka tidak melihat potensi komersial dalam meningkatkan keandalan.
Apa yang harus dilakukan
Secara lokal, Delimobil perlu menyelesaikan masalah parkir di Skolkovo. Banyak mobil idle di sana. Tidak mungkin mereka akan setuju dengan operator seluler untuk meningkatkan kualitas komunikasi. Oleh karena itu, hasil yang paling memungkinkan bagi saya adalah mereka akan melarang parkir di sana dan mengangkut kendaraan ke Moskow sendiri. Hasil yang menyedihkan :( Apakah Anda pikir mungkin untuk menyelesaikan masalah ini dengan cara yang berbeda?
Secara global - manajer teknis harus mempertahankan kebutuhan untuk meningkatkan keandalan. Setidaknya di Delimobile, mereka sekarang memiliki argumen.
PS Terima kasih khusus kepada orang-orang dukungan teknis tersiksa. Mereka sopan dan mencoba menyelesaikan masalah.