Kebetulan itu acak, dan memang terjadi di planet lain...
Saya ingin berbagi tiga kisah sukses dan kegagalan tentang cara backend developer bekerja dalam tim dengan admin.
Sejarah dulu.
Web studio, jumlah karyawannya bisa dihitung dengan satu tangan. Hari ini Anda adalah seorang layout designer, besok Anda adalah seorang backender, lusa Anda adalah seorang admin. Di satu sisi, Anda bisa mendapatkan pengalaman yang luar biasa. Di sisi lain, kompetensi di segala bidang masih kurang. Saya masih ingat hari pertama kerja, saya masih hijau, bos bilang: “Buka dempul”, tapi saya tidak tahu apa itu. Komunikasi dengan admin dikecualikan, karena Anda sendiri adalah seorang admin. Mari kita pertimbangkan pro dan kontra dari situasi ini.
+ Semua kekuasaan ada di tangan Anda.
+ Tidak perlu meminta akses ke server kepada siapa pun.
+ Waktu reaksi cepat ke segala arah.
+ Meningkatkan keterampilan dengan baik.
+ Memiliki pemahaman lengkap tentang arsitektur produk.
– Tanggung jawab yang tinggi.
— Risiko gangguan produksi.
— Sulit untuk menjadi spesialis yang baik di segala bidang.
Tidak tertarik, ayo lanjutkan
Cerita kedua.
Perusahaan besar, proyek besar. Ada departemen administrasi dengan 5-7 karyawan dan beberapa kelompok pengembangan. Ketika Anda datang untuk bekerja di perusahaan seperti itu, setiap admin berpikir bahwa Anda tidak datang ke sini untuk mengerjakan suatu produk, tetapi untuk memecahkan sesuatu. Baik NDA yang ditandatangani maupun seleksi wawancara tidak menunjukkan sebaliknya. Tidak, pria ini datang ke sini dengan tangan kecilnya yang kotor untuk merusak produksi ciuman kami. Oleh karena itu, dengan orang seperti itu Anda memerlukan komunikasi minimal, paling tidak, Anda dapat melempar stiker sebagai tanggapan. Jangan menjawab pertanyaan tentang arsitektur proyek. Disarankan untuk tidak memberikan akses sampai ketua tim memintanya. Dan ketika dia meminta, dia akan mengembalikannya dengan keistimewaan yang lebih sedikit dari yang mereka minta. Hampir semua komunikasi dengan admin tersebut diserap oleh lubang hitam antara departemen pengembangan dan departemen administrasi. Tidak mungkin menyelesaikan masalah dengan segera. Tapi Anda tidak bisa datang sendiri - adminnya terlalu sibuk 24/7. (Apa yang Anda lakukan sepanjang waktu?) Beberapa karakteristik kinerja:
- Waktu penerapan rata-rata dalam produksi adalah 4-5 jam
- Waktu penerapan maksimum dalam produksi 9 jam
- Bagi seorang pengembang, aplikasi dalam produksi adalah kotak hitam, sama seperti server produksi itu sendiri. Totalnya ada berapa?
- Kualitas rilis rendah, sering terjadi kesalahan
- Pengembang tidak berpartisipasi dalam proses rilis
Nah, yang saya harapkan, tentu saja orang baru tidak boleh masuk produksi. Baiklah, setelah bersabar, kita mulai mendapatkan kepercayaan orang lain. Tetapi untuk beberapa alasan, hal-hal tidak sesederhana itu dengan admin.
Babak 1. Admin tidak terlihat.
Hari rilis, pengembang dan admin tidak berkomunikasi. Admin tidak punya pertanyaan. Tapi Anda mengerti alasannya nanti. Admin adalah orang yang berprinsip, tidak memiliki messenger, tidak memberikan nomor teleponnya kepada siapapun, dan tidak memiliki profil di jejaring sosial. Bahkan tidak ada fotonya di mana pun, seperti apa rupamu kawan? Kami duduk dengan manajer yang bertanggung jawab selama sekitar 15 menit dalam kebingungan, mencoba menjalin komunikasi dengan Voyager 1 ini, kemudian sebuah pesan muncul di email perusahaan bahwa dia telah selesai. Apakah kita akan berkorespondensi melalui surat? Mengapa tidak? Nyaman, bukan? Baiklah, mari kita tenangkan diri. Prosesnya sudah berjalan, tidak ada jalan untuk mundur. Baca pesan itu lagi. "Saya sudah selesai". Apa yang sudah kamu selesaikan? Di mana? Kemana aku harus mencarimu? Di sini Anda memahami mengapa 4 jam untuk rilis adalah normal. Kami mendapat kejutan pengembangan, tetapi kami menyelesaikan rilisnya. Tidak ada lagi keinginan untuk melepaskan.
Babak 2. Bukan versi itu.
Rilis berikutnya. Setelah mendapatkan pengalaman, kami mulai membuat daftar perangkat lunak dan perpustakaan yang diperlukan untuk server untuk administrator, menunjukkan versi untuk beberapa versi. Seperti biasa, kami menerima sinyal radio lemah bahwa admin telah menyelesaikan sesuatu di sana. Uji regresi dimulai, yang memakan waktu sekitar satu jam. Segalanya tampaknya berfungsi, tetapi ada satu bug kritis. Fungsi penting tidak berfungsi. Beberapa jam berikutnya adalah menari dengan rebana, meramal di ampas kopi, dan meninjau secara detail setiap potongan kode. Admin bilang dia sudah melakukan semuanya. Aplikasi yang ditulis oleh pengembang nakal tidak berfungsi, tetapi server berfungsi. Ada pertanyaan untuknya? Pada akhir satu jam, kami meminta admin mengirimkan versi perpustakaan di server produksi ke dalam obrolan dan bingo - itu bukan yang kami butuhkan. Kami meminta administrator untuk menginstal versi yang diperlukan, tetapi sebagai tanggapan kami menerima bahwa dia tidak dapat melakukan ini karena tidak adanya versi ini di manajer paket OS. Di sini, dari relung ingatannya, manajer mengingat bahwa admin lain telah memecahkan masalah ini hanya dengan merakit versi yang diperlukan dengan tangan. Tapi tidak, kami tidak akan melakukan ini. Peraturan melarang. Karl, kita sudah duduk di sini selama beberapa jam, berapa batas waktunya?! Kami mendapat kejutan lain dan entah bagaimana menyelesaikan rilisnya.
Babak 3, pendek
Tiket mendesak, fungsi utama tidak berfungsi untuk salah satu pengguna dalam produksi. Kami menghabiskan beberapa jam untuk menyodok dan memeriksa. Di lingkungan pengembangan, semuanya berfungsi. Ada pemahaman yang jelas bahwa sebaiknya melihat log php-fpm. Tidak ada sistem log seperti ELK atau Prometheus pada proyek tersebut pada saat itu. Kami membuka tiket ke departemen administrasi sehingga mereka memberikan akses ke log php-fpm di server. Di sini perlu Anda pahami bahwa kami meminta akses karena suatu alasan, ingatkah Anda tentang lubang hitam dan admin yang sibuk 24/7? Jika Anda meminta mereka untuk melihat sendiri lognya, maka ini adalah tugas dengan prioritas “tidak dalam kehidupan ini”. Tiket telah dibuat, kami menerima tanggapan instan dari kepala departemen administrasi: “Anda tidak memerlukan akses ke log produksi, tulis tanpa bug.” Sebuah tirai.
Babak 4 dan seterusnya
Kami masih mengumpulkan lusinan masalah dalam produksi, karena versi perpustakaan yang berbeda, perangkat lunak yang tidak dikonfigurasi, beban server yang tidak siap, dan masalah lainnya. Tentu saja, ada juga bug kode, kami tidak akan menyalahkan admin atas semua dosanya, kami hanya akan menyebutkan satu lagi operasi umum untuk proyek itu. Kami memiliki cukup banyak pekerja latar belakang yang diluncurkan melalui supervisor, dan beberapa skrip harus ditambahkan ke cron. Terkadang para pekerja ini berhenti bekerja. Beban pada server antrian bertambah dengan kecepatan kilat, dan pengguna yang sedih melihat pemuat yang berputar. Untuk memperbaiki pekerja seperti itu dengan cepat, cukup dengan memulai ulang saja, tetapi sekali lagi, hanya administrator yang dapat melakukan ini. Sementara operasi dasar seperti itu dilakukan, satu hari penuh bisa berlalu. Di sini, tentu saja, perlu dicatat bahwa pemrogram yang bengkok harus menulis pekerja agar tidak mogok, tetapi ketika mereka jatuh, alangkah baiknya untuk memahami alasannya, yang terkadang tidak mungkin karena kurangnya akses ke produksi, dari Tentu saja, dan sebagai konsekuensinya, kurangnya log dari pengembang.
Transfigurasi.
Setelah menanggung semua ini dalam waktu yang cukup lama, bersama tim kami mulai mengarahkan ke arah yang lebih sukses bagi kami. Ringkasnya, masalah apa yang kita hadapi?
- Kurangnya komunikasi yang berkualitas antara pengembang dan departemen administrasi
- Administrator, ternyata (!), tidak memahami sama sekali bagaimana aplikasi tersebut disusun, dependensi apa yang dimilikinya, dan cara kerjanya.
- Pengembang tidak memahami cara kerja lingkungan produksi dan, akibatnya, tidak dapat merespons masalah secara efektif.
- Proses penerapannya memakan waktu terlalu lama.
- Rilis yang tidak stabil.
Apa yang telah kita lakukan?
Untuk setiap rilis, daftar Catatan Rilis dibuat, yang mencakup daftar pekerjaan yang perlu dilakukan di server agar rilis berikutnya dapat berfungsi. Daftar tersebut berisi beberapa bagian, pekerjaan yang harus dilakukan oleh administrator, orang yang bertanggung jawab atas rilis, dan pengembang. Pengembang menerima akses non-root ke semua server produksi, yang mempercepat pengembangan secara umum dan penyelesaian masalah pada khususnya. Pengembang juga memiliki pemahaman tentang cara kerja produksi, layanan apa yang dibagi, di mana, dan berapa biaya replika. Beberapa beban tempur menjadi lebih jelas, yang tidak diragukan lagi mempengaruhi kualitas kode. Komunikasi selama proses rilis berlangsung di chat salah satu instant messenger. Pertama, kami memiliki catatan semua tindakan, dan kedua, komunikasi terjadi dalam lingkungan yang lebih dekat. Memiliki riwayat tindakan lebih dari sekali memungkinkan karyawan baru menyelesaikan masalah dengan lebih cepat. Ini sebuah paradoks, tetapi hal ini sering kali membantu admin itu sendiri. Saya tidak akan mengatakan dengan pasti, tetapi menurut saya admin sudah mulai lebih memahami cara kerja proyek dan cara penulisannya. Kadang-kadang kami bahkan berbagi beberapa detail satu sama lain. Waktu rilis rata-rata telah dikurangi menjadi satu jam. Terkadang kami selesai dalam 30-40 menit. Jumlah bug telah berkurang secara signifikan, bahkan sepuluh kali lipat. Tentu saja, faktor lain juga mempengaruhi pengurangan waktu rilis, seperti autotest. Setelah setiap rilis, kami mulai melakukan retrospektif. Sehingga seluruh tim mempunyai gambaran apa yang baru, apa yang diubah, dan apa yang dihilangkan. Sayangnya admin tidak selalu datang menemui mereka, nah admin sedang sibuk... Kepuasan kerja saya sebagai developer tentu saja meningkat. Ketika Anda dapat dengan cepat menyelesaikan hampir semua masalah yang ada dalam bidang kompetensi Anda, Anda merasa berada di puncak. Nanti, saya akan memahami bahwa sampai batas tertentu kita memperkenalkan budaya devops, tentu saja tidak sepenuhnya, tetapi bahkan awal transformasi itu pun sangat mengesankan.
cerita tiga
Rintisan. Satu admin, departemen pengembangan kecil. Setibanya di sana, saya benar-benar nol, karena... Saya tidak memiliki akses ke mana pun kecuali dari surat. Kami menulis kepada admin dan meminta akses. Selain itu, ada informasi bahwa dia mengetahui karyawan baru dan perlunya mengeluarkan login/kata sandi. Mereka memberikan akses dari repositori dan VPN. Mengapa memberikan akses ke wiki, teamcity, rundesk? Hal-hal yang tidak berguna bagi seseorang yang dipanggil untuk menulis seluruh bagian backend. Hanya seiring berjalannya waktu kami mendapatkan akses ke beberapa alat. Kedatangannya tentu saja disambut dengan ketidakpercayaan. Saya mencoba untuk perlahan-lahan memahami cara kerja infrastruktur proyek melalui obrolan dan pertanyaan-pertanyaan yang mengarahkan. Pada dasarnya saya tidak mengenali apa pun. Produksinya adalah kotak hitam yang sama seperti sebelumnya. Namun lebih dari itu, bahkan server panggung yang digunakan untuk pengujian pun merupakan kotak hitam. Kami tidak dapat melakukan apa pun selain menerapkan cabang dari Git di sana. Kami juga tidak dapat mengkonfigurasi aplikasi kami seperti file .env. Akses untuk operasi semacam itu tidak diberikan. Anda harus meminta agar baris diubah dalam konfigurasi aplikasi Anda di server pengujian. (Ada teori bahwa sangat penting bagi admin untuk merasa diri mereka penting dalam proyek; jika mereka tidak diminta untuk mengubah baris dalam konfigurasi, mereka tidak akan diperlukan). Seperti biasa, bukankah ini nyaman? Ini dengan cepat menjadi membosankan, setelah percakapan langsung dengan admin kami mengetahui bahwa pengembang dilahirkan untuk menulis kode yang buruk, pada dasarnya adalah individu yang tidak kompeten dan lebih baik menjauhkan mereka dari produksi. Tapi di sini juga dari server uji, untuk berjaga-jaga. Konflik meningkat dengan cepat. Tidak ada komunikasi dengan admin. Situasi ini diperburuk oleh kenyataan bahwa dia sendirian. Berikut gambaran tipikalnya. Melepaskan. Fungsi tertentu tidak berfungsi. Butuh waktu lama bagi kami untuk mengetahui apa yang terjadi, berbagai ide dari developer dilontarkan ke dalam chat, namun admin dalam situasi seperti ini biasanya berasumsi bahwa developerlah yang harus disalahkan. Lalu dia menulis di chat, tunggu, saya koreksi dia. Ketika diminta untuk meninggalkan cerita dengan informasi tentang apa masalahnya, kami menerima alasan yang beracun. Seperti, jangan menempelkan hidungmu di tempat yang bukan tempatnya. Pengembang harus menulis kode. Situasi ketika banyak gerakan tubuh dalam sebuah proyek dilakukan oleh satu orang dan hanya dia yang memiliki akses untuk melakukan operasi yang dibutuhkan semua orang sangatlah menyedihkan. Orang seperti itu adalah hambatan yang parah. Jika ide-ide Devops berupaya mengurangi waktu pemasaran, maka orang-orang seperti itu adalah musuh terburuk ide-ide Devops. Sayangnya, tirai ditutup di sini.
PS Setelah berbicara sedikit tentang pengembang vs admin dalam obrolan dengan orang-orang, saya bertemu orang-orang yang berbagi kepedihan saya. Namun ada juga yang mengaku belum pernah menemui hal seperti ini. Pada salah satu konferensi devops, saya bertanya kepada Anton Isanin (Alfa Bank) bagaimana mereka mengatasi masalah kemacetan dalam bentuk admin, dan dia berkata: “Kami menggantinya dengan tombol.” Omong-omong dengan partisipasinya. Saya percaya bahwa ada lebih banyak admin yang baik daripada musuh. Dan ya, gambar di awal adalah korespondensi nyata.
Sumber: www.habr.com