Terjemahan artikel disiapkan khusus untuk siswa kursus Praktek dan Alat DevOps .
Misi Intercom adalah menjadikan bisnis online lebih personal. Tetapi mempersonalisasikan suatu produk tidak mungkin ketika itu tidak berfungsi
sebagaimana mestinya . Efisiensi sangat penting untuk keberhasilan bisnis kami, dan bukan hanya karena pelanggan kami membayar kami, tetapi juga karena kami menggunakan
produk kami sendiri. Jika layanan kami tidak berfungsi, kami benar-benar merasakan sakitnya pelanggan kami.
Uptime tergantung pada banyak faktor, seperti arsitektur perangkat lunak dan kualitas pekerjaan sehari-hari. Namun, cukup sering itu semua bermuara pada kenyataan bahwa seseorang yang selalu berhubungan menjawab panggilan dari
PagerDuty . Dukungan teknis seperti itu dapat menjadi alat berorientasi pelanggan yang kuat yang menggabungkan bantuan insinyur dengan apa yang pelanggan terima ketika mereka membeli produk Anda. Ini juga menawarkan kesempatan besar untuk belajar dan tumbuh, karena pada akhirnya, kegagalan dan kesalahan dapat menjadi bidang yang baik untuk mengembangkan keterampilan dan memahami mekanisme kerja yang kompleks.
Tetap "selalu berhubungan" di luar jam kerja merugikan kehidupan Anda.Tetapi pada saat yang sama, keadaan "selalu berhubungan" dapat memiliki efek yang merugikan pada hidup Anda. Anda harus siap dengan cepat dan kompeten menanggapi peringatan bahwa ada sesuatu yang rusak. Bahkan jika Anda tidak dipanggil oleh pager pada saat tertentu, keadaan "selalu berhubungan" menanamkan perasaan cemas, saya sendiri tahu ini dari pengalaman pribadi. Terutama karena ini, kualitas tidur memburuk. Tinggal secara teratur di area akses setiap saat sepanjang hari dapat menyebabkan kelelahan, apatis, atau secara umum keinginan untuk tidak pernah melihat komputer lagi.
Riwayat status interkom di Interkom
Pada hari-hari pertama Intercom, direktur teknis kami Kiaran sendiri adalah seluruh tim dukungan teknis sepanjang waktu, baik di kantor maupun di luar. Ketika Intercom tumbuh, sebuah gugus tugas dibentuk untuk membantu Ciaran. Segera setelah itu, tim pengembangan baru mulai membuat banyak fitur dan layanan baru, dan mereka sudah mengambil sendiri semua tanggung jawab dukungan teknis.
Setiap saat ada terlalu banyak orang yang “berhubungan”.Pada saat itu, pendekatan ini tampaknya diterima begitu saja, karena itu adalah cara mudah untuk skala tim dukungan teknis setiap saat, itu memenuhi nilai-nilai kami dan menghibur
rasa kepemilikan kami . Akibatnya, tanpa rencana apa pun, kami mendapat empat atau lima tim yang secara teratur menghubungi pelanggan selama jam-jam kerja setelahnya. Anggota tim pengembang lainnya tidak memiliki banyak momen sulit yang dapat menimbulkan kesalahan, sehingga mereka jarang, jika pernah, dipanggil.
Kami menyadari bahwa kami berada dalam situasi di mana kami memiliki mekanisme dukungan teknis, yang tidak dapat dibanggakan, dan sejumlah masalah kritis yang ingin kami hilangkan, seperti:
- Terlalu banyak orang yang siap menerima tantangan pada waktu tertentu. Infrastruktur kami tidak begitu besar sehingga diperlukan minimal lima insinyur pengembangan yang akan bekerja tanpa akhir pekan yang normal.
- Kualitas alarm dan prosedur panggilan kami tidak terkoordinasi antara tim, kami menggunakan proses khusus untuk meninjau peringatan baru dan yang ada tentang masalah. Instruksi dalam runbook (yang harus diikuti ketika menerima pemberitahuan tentang masalah) sebagian besar mencolok saat mereka tidak ada.
- Tergantung pada tim di mana para insinyur bekerja, mereka memiliki harapan yang bertentangan. Sebagai contoh, hanya tim dukungan teknis pertama yang memiliki kompensasi untuk pengalihan tugas dan akhir pekan yang rusak.
- Ternyata ada tingkat toleransi umum untuk panggilan yang tidak perlu pada waktu yang tidak tepat.
- Akhirnya, jenis pekerjaan ini tidak cocok untuk semua orang. Keadaan kehidupan kadang-kadang menunjukkan bahwa pengalihan tugas memengaruhi orang bukan dengan cara terbaik.
Cari status "selalu berhubungan" yang benar
Kami memutuskan untuk membuat tim virtual baru yang akan melakukan pekerjaan dukungan teknis untuk setiap tim ketika memiliki waktu yang tidak bekerja. Tim akan terdiri dari sukarelawan, bukan wajib militer dari tim mana pun dalam organisasi. Insinyur di tim virtual berubah setiap enam bulan, menghabiskan minggu “berhubungan”. Untungnya, kami tidak kesulitan menemukan cukup sukarelawan untuk membentuk tim virtual.
Hasilnya, tim pendukung kami berkurang dari 30 orang menjadi hanya 6 atau 7.Tim ini kemudian menyetujui dan menentukan seperti apa peringatan dan deskripsi masalah di runbook, dan menjelaskan proses meneruskan peringatan ke tim pendukung yang baru. Mereka mengidentifikasi semua peringatan dalam kode menggunakan modul Terraform, dan mulai menggunakan penilaian ahli untuk setiap perubahan. Kami memperkenalkan tingkat kompensasi untuk shift mingguan, yang cukup cocok untuk mereka yang bertugas. Kami juga menciptakan tim tingkat kedua yang meningkat, yang hanya terdiri dari para manajer. Tim ini harus menjadi satu-satunya titik eskalasi untuk insinyur dukungan teknis.
Kami memiliki beberapa bulan kerja keras, di mana kami memulai proses ini, sebagai hasilnya, sekarang bukan 30 insinyur seperti sebelumnya, tetapi hanya 6 atau 7 yang tetap berhubungan. Selama jam kerja, tim secara mandiri menangani masalah dengan fungsi atau layanan mereka, di kali ini biasanya merupakan jumlah kerusakan terbesar, namun, sisa waktu sukarelawan terlibat dalam dukungan teknis.
Apa yang kami pelajari
Setelah kami meluncurkan tim dukungan teknis virtual kami, kami mengharapkan masuknya tugas-tugas baru, seperti menyelidiki penyebab masalah atau pengumpulan umum untuk menyelesaikan satu masalah yang menyebabkan kegagalan. Namun, tim pengembangan kami bertanggung jawab penuh atas faktor-faktor penyebab kegagalan, dan setiap reaksi selanjutnya biasanya tindakan segera. Kami juga perlu menghindari situasi di mana tugas saran teknis akan dikembalikan kembali ke tim dari mana ia datang, sehingga tidak memaksa para insinyur untuk menghubungi setelah berjam-jam.
Panggilan ke luar kantor menurun menjadi kurang dari 10 per bulan.Secara formal, proses eskalasi kami jarang digunakan. Pendapat yang lebih umum adalah bahwa insinyur, yang saat ini online, membantu insinyur secara informal, terutama untuk orang-orang kami dari kantor di San Francisco. Banyak masalah yang diperbaiki atau jumlah mereka dikurangi melalui kerja tim dan menyelesaikannya dengan cepat.
Para insinyur di kantor kami di San Francisco bergabung dengan tim secara keseluruhan dan melampaui dukungan teknis yang biasa. Kami dihadapkan dengan pertanyaan tentang biaya overhead tertentu, tetapi memperluas keanggotaan tim dukungan kami ke beberapa kantor, yang ternyata menjadi cara yang baik untuk membangun hubungan, memperkuat mereka dan belajar lebih banyak tentang tumpukan teknologi yang kita semua kerjakan.
Di tim kami, pekerjaan pengembang Intercom menjadi lebih konsisten, dan kami dapat dengan percaya diri berbicara tentang keuntungan dari posisi insinyur sistem di situs web
Karier kami, yang menyatakan bahwa tidak perlu selalu berhubungan jika Anda tidak menginginkannya sendiri.
Seiring dengan pekerjaan mendasar untuk menstabilkan dan menskalakan gudang data kami, perhatian terus-menerus untuk memecahkan masalah telah mengarah pada fakta bahwa jumlah panggilan selama jam kerja dikurangi menjadi kurang dari 10 per bulan. Kami sangat bangga dengan nomor ini.
Kami terus bekerja pada pemeliharaan dan peningkatan tim dukungan teknis kami, dan seiring berkembangnya Intercom, kami mungkin harus mempertimbangkan kembali keputusan kami, karena apa yang berhasil hari ini tidak harus bekerja pada saat jumlah karyawan kami berlipat ganda. Namun demikian, pengalaman ini sangat positif bagi organisasi kami, itu secara signifikan meningkatkan kualitas hidup para insinyur pengembangan kami, kualitas tanggapan kami terhadap tantangan, dan, yang terpenting, pengalaman pelanggan kami.