Banyak yang telah dikatakan tentang keuntungan bekerja di perusahaan grosir, dan sulit untuk menjadi orisinal di sini. Namun jauh dari semua orang tahu bagaimana menjaga "kesehatan" suatu produk dan apa yang mungkin dilakukan di perusahaan makanan, selain mengembangkan fungsionalitas. Kami akan memberi tahu Anda bagaimana kami mengoperasikan produk di Juno, dan bagaimana departemen operasi dan spesialis teknis terlibat dalam hal ini.
Kami tidak menyatakan bahwa jalan kami adalah yang paling benar. Kami terus mencoba, membuat kesalahan, dan mencoba untuk belajar dari kesalahan kami. Kami berharap pengalaman kami akan bermanfaat bagi Anda.
Tentang kami: Juno adalah layanan persembunyian perjalanan yang beroperasi di pasar AS dan bagian dari grup perusahaan Gett.
Juno menulis kode dalam bahasa Go, Swift, Kotlin, Python, React.js sebagai bagian dari tim aplikasi seluler, Backend, Frontend, Ilmu Data, Dukungan Operasi Teknis, menciptakan layanan yang telah menjadi bagian dari kehidupan sehari-hari puluhan ribu pengemudi dan ratusan ribu penduduk baru York.
Tentang apa manajemen produk
Mari kita memahami proses operasi di Juno dan mencoba menguraikannya menjadi bagian-bagian penyusunnya.
Kami telah mengidentifikasi tiga komponen utama untuk diri kami sendiri:
- Kantor operasional
- Metrik dan Pemantauan
- Investigasi insiden
Tujuan pengoperasian produk adalah untuk merespons secara tepat waktu terhadap masalah dan perubahan yang muncul, terlepas dari sifatnya.
Untuk melakukan ini, Anda perlu:
- Tetapkan indikator kesehatan sistem
- Memahami bagaimana perubahan dalam sistem memengaruhi metrik
- Memahami bagaimana perubahan pasar mempengaruhi kinerja
- Memahami kapan perubahan tumbuh menjadi masalah
Dengan pendekatan ini, keputusan bisnis didasarkan pada data. Tim operasi kami bekerja di New York, karena layanan Juno saat ini hanya tersedia untuk penduduk kota metropolis ini.
Daftar tugas harian tim terlihat seperti ini:
- Lacak dan tanggapi dengan cepat perubahan regulasi. Perubahan umum termasuk penampilan jalan tol baru dan transfer area tunggu untuk pengemudi di bandara. Segera setelah kami menerima informasi tentang peristiwa semacam itu, karyawan meninggalkan tempat untuk memperbarui peta dengan benar dan menganalisis daftar masalah yang mungkin terjadi. Ketika tim pengembangan memperbarui peta di server, karyawan menguji perubahan dalam "kondisi lapangan" dan memastikan bahwa itu berfungsi dengan benar.
- Melakukan penelitian "lapangan". Ketika kami meluncurkan layanan di New York, rencananya adalah merekrut terlebih dahulu sejumlah pengemudi untuk operasi layanan yang stabil di wilayah kota mana pun. Karena alasan ini, selama beberapa bulan, pengemudi yang bergabung dengan kami pertama kali mengemudi tanpa penumpang dan hanya sesekali menerima perjalanan dari penguji beta. Perjalanan ini tidak cukup untuk mengumpulkan informasi yang diperlukan. Kemudian kami memutuskan untuk mengirim tim operasi ke "ladang" untuk mengevaluasi kualitas layanan dan mencari tahu keluhan pengemudi tentang aplikasi tersebut. Pendekatan ini ternyata bermanfaat dan kami terus menggunakannya ketika mengeluarkan perubahan signifikan atau untuk menguji hipotesis.
- Berita "Kalender Acara" - daftar acara, liburan, dan acara cuaca yang dapat memengaruhi kuantitas dan kualitas perjalanan. Ini membantu untuk memahami dan mengantisipasi perubahan dalam indikator utama (misalnya, jumlah perjalanan atau jumlah pengemudi online) yang tidak jelas bagi tim pengembangan dari Minsk. Beberapa acara dapat di-googled (kondisi cuaca, final SuperBowl, maraton, balapan sepeda, dll.), Tetapi ada beberapa yang lebih sulit. Sebagai contoh, pada tahun pertama kerja, mengejutkan kami bahwa Ramadhan sangat memengaruhi jumlah pengemudi yang mau menerima pesanan. Faktanya adalah bahwa di AS, banyak Muslim yang bekerja sebagai pengemudi, dan mereka tidak pergi bekerja pada hari libur. Sulit untuk memperhitungkan fakta seperti itu saat berada di Minsk.
- Lacak perubahan dalam metrik bisnis. Pada bulan ketiga setelah peluncuran Juno dan pertumbuhan pesat dalam jumlah perjalanan, kami menemukan bahwa tidak ada cukup pengemudi secara online, yang mempengaruhi waktu pengiriman mobil dan keinginan penumpang untuk bepergian bersama kami. Ternyata seorang pesaing meluncurkan kampanye yang menjamin pengemudi meningkatkan pembayaran untuk perjalanan di jam sibuk pagi dan sore hari. Informasi itu dengan cepat dikirim ke Minsk, dan dalam waktu singkat kami juga berkesempatan untuk menawarkan kondisi seperti itu. Langkah ini membantu kami mendapatkan driver kembali dan terus tumbuh.
Metrik dan Pemantauan
Di Juno, semua tim memiliki metrik, yang kami setujui untuk dibagi menjadi:
- Metrik bisnis.
- Metrik teknis.
Metrik bisnis adalah serangkaian indikator yang mengukur “kesehatan” suatu produk. Kami membagi mereka secara kondisional menjadi dua bagian:
- Online Yang jelas adalah jumlah pengemudi dan penumpang online, jumlah perjalanan berdasarkan status. Yang kurang jelas adalah jumlah pengguna baru, konversi dari layar dengan harga awal perjalanan ke pemesanan perjalanan, waktu tunggu rata-rata untuk mobil di area tertentu, kecepatan antrian di bandara, dll.
- Offline Tidak semua informasi dapat dengan cepat diperoleh dan diproses secara waktu nyata, dan itu tidak selalu diperlukan. Ketika kami merencanakan promosi untuk driver atau fitur baru, kami tertarik pada tren jangka panjang atau reaksi pengguna terhadap percobaan A / B, apakah itu desain baru, fungsi baru atau diskon tambahan.
Untuk membuat laporan analitik berdasarkan metrik yang dikumpulkan, kami menggunakan Tableau. Untuk laporan tersebut, kami bertanggung jawab atas tim Business Intelligence (BI). Mereka bekerja di kantor Tel Aviv di sebelah tim bahan makanan. Kedua tim bekerja sama dengan kolega di New York, yang memungkinkan analis berbasis BI untuk mengevaluasi keberhasilan tindakan yang diambil, merumuskan hipotesis untuk verifikasi di "bidang" dan menyesuaikan rencana pengembangan produk.
Di sisi lain, ada sejumlah metrik teknis yang entah bagaimana memengaruhi sistem secara keseluruhan.
Metrik teknis adalah serangkaian indikator yang menunjukkan operasi komponen individu yang bebas dari kesalahan, berdasarkan kesimpulan yang diambil tentang operasi sistem secara keseluruhan. Mereka menunjukkan berapa banyak waktu panggilan antar layanan, berapa banyak memori yang mereka konsumsi, dan jika ada kesalahan kritis saat mentransfer pesan di antara mereka. Ada banyak metrik seperti itu di Juno. Mereka agak berlebihan, tetapi dalam situasi kritis itu membantu untuk dengan cepat menemukan penyebab masalah. Melacak dan menggunakan metrik teknis membantu kami:
- Dasbor - menampilkan tanda-tanda vital yang signifikan dari sistem. Setiap tim pengembangan menyusun set metriknya sendiri yang membantu mereka memahami bagaimana suatu perubahan tertentu memengaruhi layanan-layanan mikro yang dipercayakan kepada mereka. Jadi, misalnya, satu tim memantau metrik yang terkait dengan membayar uang kepada pengemudi dan pembayaran penumpang, dan yang lain melihat metrik yang bertanggung jawab atas waktu pencarian pengemudi atau jumlah koordinat yang diterima.
- Log Kami mencatat acara dari perangkat seluler dan layanan microsoft backend. Pada 2017, mereka menghabiskan 400-500 gigabytes per minggu, pada 2018 angka ini berlipat ganda. Kami tertarik pada peristiwa-peristiwa berikut: panggilan microservices ke sumber informasi eksternal, ke microservices lain, menerima dan mengirim permintaan untuk klien, semua jenis kesalahan (bisnis dan teknis). Perlu dicatat bahwa informasi tersebut dianonimkan: data pribadi, seperti kata sandi dan informasi perbankan, tidak dicatat.
Untuk memantau kinerja, kami menggunakan Grafana dan Prometheus. Saat mengembangkan layanan baru atau menambahkan fungsi baru, pengembang menambahkan metrik yang diperlukan ke layanan, dan kemudian masing-masing tim mengatur peringatan untuk dirinya sendiri.
Berkat peringatan yang disesuaikan, tim dukungan teknis melakukan analisis awal dan meningkatkan masalah ke dalam pengembangan atau ke dalam tim bisnis untuk penyelesaian lebih lanjut.
Jika masalah bersifat teknis dan mengancam operasi normal layanan, tim dukungan teknis menciptakan insiden produksi. Berkat proses otomatis, para pemangku kepentingan segera diberitahu, termasuk tim dukungan pelanggan (layanan Pelanggan alias Helpdesk alias dukungan L1), yang sedang mempersiapkan kemungkinan masuknya panggilan.
Investigasi insiden
Seiring waktu, kami sampai pada kesimpulan bahwa setelah setiap insiden serius, semacam "tanya jawab" terjadi. Kami membuat perubahan pada proses yang membantu kami menghindari atau menangani dengan lebih baik acara serupa di masa mendatang.
Elemen yang disebutkan di atas: metrik, dasbor, peringatan, dan log membantu memahami apa yang terjadi. Tim duduk bersama, menganalisis perubahan dalam indikator teknis dan bisnis, memperhitungkan kesalahan dan mengambil pelajaran untuk diri mereka sendiri.
Kami harus berurusan dengan insiden produksi, serta dengan situasi lain di mana tidak mungkin untuk dengan cepat menjawab "apa yang terjadi". Dan di sini tim dukungan teknis membantu (TechSupport alias dukungan L2).
Masalah apa yang diselesaikan dalam dukungan teknis? Diyakini bahwa ini adalah pekerjaan yang membosankan, seperti dalam seri IT Crowd, di mana tiga kutu buku di ruang bawah tanah hanya melakukan apa yang mereka katakan: "coba matikan dan nyalakan komputer." Bahkan, pertanyaan muncul rumit dan kontroversial.
Tingkat dukungan pertama (layanan pelanggan) diatur oleh prinsip "ikuti matahari" (ikuti matahari). Dengan pendekatan ini, dukungan pengguna 24 jam dapat dilakukan tanpa shift malam. Di zaman Eropa, sebuah kantor terletak di Tel Aviv, dan di Amerika - di Portland. Tugas tim ini adalah mendengarkan dan memahami "rasa sakit" pengemudi atau penumpang, untuk menenangkan diri, untuk membantu jika memungkinkan. Orang-orang yang bekerja di sana bertanggung jawab atas pertanyaan tentang pengoperasian layanan. Pada saat yang sama, tim tidak “teknis”, dan begitu saatnya tiba ketika perlu untuk menyelami lebih dalam nuansa teknis, permintaan tersebut dialihkan ke tim dukungan teknis. Tim ini bekerja di Minsk dan merupakan bagian dari pusat pengembangan. Mereka menyelesaikan masalah teknis secara eksklusif dan tidak berkomunikasi dengan pengemudi dan penumpang secara langsung. Tugas tim: investigasi insiden dan otomatisasi proses.
Dalam kasus insiden produksi, tugas tim dukungan teknis adalah sebagai berikut: bug ditemukan atau kegagalan terjadi selama penyebaran, kami melihat masalah, memperbaikinya, tetapi kami masih perlu mencari tahu bagaimana hal itu mempengaruhi sistem dan apa yang perlu dipulihkan dari sudut pandang manajemen produk:
- Apakah data rusak atau integritasnya dilanggar?
- Bagaimana kejadian ini memengaruhi pengguna?
- Apakah semua pengguna terpengaruh?
- Apa yang bisa diperbaiki?
Pertanyaannya sederhana, tetapi untuk menjawabnya, Anda perlu memahami dengan baik bagaimana sistem bekerja dan bagaimana perilakunya berubah selama insiden. Saat menjawab pertanyaan, ada baiknya mempertimbangkan proses penyebaran yang sedang berlangsung, karena kemungkinan bahwa sesuatu dapat berubah setiap menit.
Sebagai contoh, ketika dukungan teknis diperlukan agar produk berfungsi dengan benar, pertimbangkan kasus “Saya tidak melakukan perjalanan”. Sopir mengambil penumpang lain dan melakukan perjalanan yang tidak ingin dibayar penumpang kami. Dalam hal ini, perlu untuk membedakan antara permintaan yang sah dan upaya penipuan ketika pengguna mencoba untuk tidak membayar layanan yang diberikan.
Jika permintaan datang berulang kali, itu otomatis oleh tim dukungan teknis dan diberikan kepada tim dukungan pengguna dalam bentuk aplikasi web. Pendekatan ini memungkinkan Anda untuk mengurangi waktu yang dibutuhkan untuk memproses permintaan pengguna dan tidak "mengembang" tim dukungan teknis. Namun demikian, kekosongan insinyur dukungan teknis selalu terbuka untuk kita, karena orang-orang tumbuh dan pindah ke tim pengembangan lainnya.
Semua jalan menuju Roma
Penjelasan terperinci tentang pekerjaan tim dukungan teknis dalam kerangka kerja artikel ini tidak disengaja. Kebetulan itu menjadi tempat di mana informasi mengalir dari semua sumber. Satu titik kontak mengurangi jumlah penerjemah, dan karenanya mengurangi jumlah distorsi.
Ini tidak berarti bahwa tim dukungan teknis adalah mata rantai utama dalam mengelola produk operasi, karena perusahaan produk adalah organisme hidup: semua organ adalah penting dan perlu. Tidak mungkin untuk memilih apa yang lebih penting bagi seseorang - otak atau jantung, paru-paru atau sistem peredaran darah. Hanya perkembangan dan interaksi yang harmonis dari semua organ yang menjamin berfungsinya tubuh atau perusahaan IT secara sehat.
Kesehatan untuk Anda dan produk Anda!