Pembangun adalah dari Marikh, Pentadbir dari Venus

Kebetulan adalah rawak, dan sememangnya ia berlaku di planet lain...

Saya ingin berkongsi tiga kisah kejayaan dan kegagalan tentang cara pembangun bahagian belakang berfungsi dalam satu pasukan dengan pentadbir.

Cerita satu.
Studio web, bilangan pekerja boleh dikira dengan satu tangan. Hari ini anda adalah pereka susun atur, esok anda menjadi backender, lusa anda menjadi admin. Di satu pihak, anda boleh memperoleh pengalaman yang luar biasa. Sebaliknya, terdapat kekurangan kecekapan dalam semua bidang. Saya masih ingat hari pertama bekerja, saya masih hijau, bos berkata: "Buka dempul," tetapi saya tidak tahu apa itu. Komunikasi dengan pentadbir dikecualikan, kerana anda sendiri adalah admin. Mari kita pertimbangkan kebaikan dan keburukan keadaan ini.

+ Segala kuasa ada di tangan anda.
+ Tidak perlu meminta sesiapa untuk mengakses pelayan.
+ Masa tindak balas pantas dalam semua arah.
+ Meningkatkan kemahiran dengan baik.
+ Mempunyai pemahaman yang lengkap tentang seni bina produk.

- Tanggungjawab yang tinggi.
- Risiko memecahkan pengeluaran.
— Sukar untuk menjadi pakar yang baik dalam semua bidang.

Tidak berminat, mari kita teruskan

Kisah kedua.
Syarikat besar, projek besar. Terdapat jabatan pentadbiran dengan 5-7 pekerja dan beberapa kumpulan pembangunan. Apabila anda datang untuk bekerja di syarikat sedemikian, setiap pentadbir berpendapat bahawa anda datang ke sini bukan untuk bekerja pada produk, tetapi untuk memecahkan sesuatu. NDA yang ditandatangani mahupun pemilihan semasa temu duga tidak menunjukkan sebaliknya. Tidak, lelaki ini datang ke sini dengan tangan kecilnya yang kotor untuk merosakkan produksi ciuman kami. Oleh itu, dengan orang sedemikian anda memerlukan komunikasi minimum; sekurang-kurangnya, anda boleh melemparkan pelekat sebagai tindak balas. Jangan jawab soalan tentang seni bina projek. Adalah dinasihatkan untuk tidak memberikan akses sehingga ketua pasukan meminta. Dan apabila dia meminta, dia akan mengembalikannya dengan keistimewaan yang lebih sedikit daripada yang mereka minta. Hampir semua komunikasi dengan pentadbir sedemikian diserap oleh lubang hitam antara jabatan pembangunan dan jabatan pentadbiran. Adalah mustahil untuk menyelesaikan masalah dengan segera. Tetapi anda tidak boleh datang sendiri - pentadbir terlalu sibuk 24/7. (Apa yang anda lakukan sepanjang masa?) Beberapa ciri prestasi:

• Purata masa penggunaan untuk pengeluaran ialah 4-5 jam
• Masa penggunaan maksimum dalam pengeluaran 9 jam
• Bagi pembangun, aplikasi dalam pengeluaran adalah kotak hitam, sama seperti pelayan pengeluaran itu sendiri. Berapakah jumlah kesemuanya?
• Kualiti keluaran yang rendah, ralat yang kerap
• Pembangun tidak mengambil bahagian dalam proses keluaran

Nah, apa yang saya jangkakan, sudah tentu, orang baru tidak dibenarkan masuk ke dalam produksi. Baiklah, okey, setelah mendapat kesabaran, kita mula mendapat kepercayaan orang lain. Tetapi atas sebab tertentu, perkara tidak begitu mudah dengan pentadbir.

Akta 1. Pentadbir tidak kelihatan.
Hari keluaran, pembangun dan pentadbir tidak berkomunikasi. Admin tiada soalan. Tetapi anda faham mengapa kemudian. Pentadbir adalah seorang yang berprinsip, tidak mempunyai utusan, tidak memberikan nombor telefonnya kepada sesiapa, dan tidak mempunyai profil di rangkaian sosial. Tidak ada gambar dia di mana-mana, bagaimana rupa anda kawan? Kami duduk dengan pengurus yang bertanggungjawab selama kira-kira 15 minit dalam kebingungan, cuba mewujudkan komunikasi dengan Voyager 1 ini, kemudian mesej muncul dalam e-mel korporat yang telah dia selesaikan. Adakah kita akan menyurat melalui surat? Kenapa tidak? Mudah, bukan? Baiklah, baiklah, mari bertenang. Prosesnya sudah berjalan, tidak boleh berpatah balik. Baca semula mesej itu. "Saya selesai". Apa yang anda selesaikan? di mana? Di mana saya harus mencari awak? Di sini anda faham mengapa 4 jam untuk dilepaskan adalah perkara biasa. Kami mendapat kejutan pembangunan, tetapi kami menyelesaikan keluarannya. Tiada lagi keinginan untuk dilepaskan.

Akta 2. Bukan versi itu.
Keluaran seterusnya. Setelah mendapat pengalaman, kami mula membuat senarai perisian dan perpustakaan yang diperlukan untuk pelayan untuk pentadbir, menunjukkan versi untuk beberapa. Seperti biasa, kami menerima isyarat radio yang lemah bahawa pentadbir telah menyelesaikan sesuatu di sana. Ujian regresi bermula, yang mengambil masa kira-kira sejam. Segala-galanya nampaknya berfungsi, tetapi terdapat satu pepijat kritikal. Fungsi penting tidak berfungsi. Beberapa jam berikutnya menari dengan tamborin, ramalan nasib di atas bubuk kopi, dan ulasan terperinci setiap kod. Admin cakap dia dah buat semua. Aplikasi yang ditulis oleh pembangun bengkok tidak berfungsi, tetapi pelayan berfungsi. Ada soalan untuk dia? Pada penghujung sejam, kami meminta pentadbir menghantar versi pustaka pada pelayan pengeluaran ke dalam sembang dan bingo - ia bukan yang kami perlukan. Kami meminta pentadbir memasang versi yang diperlukan, tetapi sebagai tindak balas kami menerima bahawa dia tidak boleh melakukan ini kerana ketiadaan versi ini dalam pengurus pakej OS. Di sini, dari ceruk ingatannya, pengurus ingat bahawa pentadbir lain telah menyelesaikan masalah ini dengan hanya memasang versi yang diperlukan dengan tangan. Tetapi tidak, kita tidak akan melakukan ini. Peraturan melarang. Karl, kita telah duduk di sini selama beberapa jam, berapa had masanya?! Kami mendapat satu lagi kejutan dan entah bagaimana menyelesaikan pelepasan.

Akta 3, pendek
Tiket segera, fungsi utama tidak berfungsi untuk salah seorang pengguna dalam pengeluaran. Kami menghabiskan beberapa jam mencucuk dan memeriksa. Dalam persekitaran pembangunan, semuanya berfungsi. Terdapat pemahaman yang jelas bahawa adalah idea yang baik untuk melihat log php-fpm. Tiada sistem log seperti ELK atau Prometheus pada projek itu pada masa itu. Kami membuka tiket ke jabatan pentadbiran supaya mereka memberi akses kepada log php-fpm pada pelayan. Di sini anda perlu memahami bahawa kami meminta akses atas sebab, tidakkah anda ingat tentang lubang hitam dan pentadbir sibuk 24/7? Jika anda meminta mereka untuk melihat log itu sendiri, maka ini adalah tugas dengan keutamaan "bukan dalam kehidupan ini". Tiket itu dibuat, kami menerima respons segera daripada ketua jabatan pentadbiran: "Anda tidak sepatutnya memerlukan akses kepada log pengeluaran, tulis tanpa pepijat." Sebuah tirai.

Akta 4 dan seterusnya
Kami masih mengumpul berpuluh-puluh masalah dalam pengeluaran, disebabkan oleh versi perpustakaan yang berbeza, perisian yang tidak dikonfigurasikan, beban pelayan yang tidak disediakan dan masalah lain. Sudah tentu, terdapat juga pepijat kod, kami tidak akan menyalahkan pentadbir untuk semua dosa, kami hanya akan menyebut satu lagi operasi biasa untuk projek itu. Kami mempunyai ramai pekerja latar belakang yang dilancarkan melalui penyelia, dan beberapa skrip terpaksa ditambahkan pada cron. Kadang-kadang pekerja yang sama ini berhenti bekerja. Beban pada pelayan barisan meningkat pada kelajuan kilat, dan pengguna sedih melihat pemuat berputar. Untuk membetulkan pekerja sedemikian dengan cepat, cukup untuk memulakan semula mereka, tetapi sekali lagi, hanya pentadbir yang boleh melakukan ini. Semasa operasi asas sedemikian sedang dilakukan, sehari suntuk boleh berlalu. Di sini, sudah tentu, perlu diperhatikan bahawa pengaturcara yang bengkok harus menulis pekerja supaya mereka tidak terhempas, tetapi apabila mereka jatuh, adalah baik untuk memahami mengapa, yang kadang-kadang mustahil kerana kekurangan akses kepada pengeluaran, kursus, dan akibatnya kekurangan log daripada pemaju.

Transfigurasi.
Setelah mengharungi semua ini untuk masa yang agak lama, bersama pasukan kami mula menuju ke arah yang lebih berjaya untuk kami. Untuk meringkaskan, apakah masalah yang kita hadapi?

• Kurangnya komunikasi yang berkualiti antara pemaju dan jabatan pentadbiran
• Pentadbir, ternyata(!), tidak faham sama sekali bagaimana aplikasi itu distrukturkan, kebergantungan apa yang ada padanya dan cara ia berfungsi.
• Pembangun tidak memahami cara persekitaran pengeluaran berfungsi dan, akibatnya, tidak dapat bertindak balas dengan berkesan kepada masalah.
• Proses penyebaran mengambil masa terlalu lama.
• Keluaran tidak stabil.

Apa yang telah kita lakukan?
Untuk setiap keluaran, senarai Nota Keluaran telah dijana, yang termasuk senarai kerja yang perlu dilakukan pada pelayan untuk keluaran seterusnya berfungsi. Senarai itu mengandungi beberapa bahagian, kerja yang harus dijalankan oleh pentadbir, orang yang bertanggungjawab untuk keluaran dan pembangun. Pembangun menerima akses bukan root kepada semua pelayan pengeluaran, yang mempercepatkan pembangunan secara umum dan penyelesaian masalah khususnya. Pembangun juga mempunyai pemahaman tentang cara pengeluaran berfungsi, perkhidmatan apa yang dibahagikan, di mana dan berapa kos replika. Beberapa beban pertempuran telah menjadi lebih jelas, yang sudah pasti menjejaskan kualiti kod. Komunikasi semasa proses pelepasan berlaku dalam sembang salah seorang pemesej segera. Pertama, kami mempunyai log semua tindakan, dan kedua, komunikasi berlaku dalam persekitaran yang lebih dekat. Mempunyai sejarah tindakan telah lebih daripada sekali membolehkan pekerja baharu menyelesaikan masalah dengan lebih cepat. Ini adalah paradoks, tetapi ini sering membantu pentadbir sendiri. Saya tidak akan mengaku pasti, tetapi nampaknya pentadbir telah mula memahami lebih lanjut cara projek itu berfungsi dan cara ia ditulis. Kadang-kadang kami juga berkongsi beberapa butiran antara satu sama lain. Purata masa keluaran telah dikurangkan kepada satu jam. Kadang-kadang kami selesai dalam 30-40 minit. Bilangan pepijat telah menurun dengan ketara, jika tidak sepuluh kali ganda. Sudah tentu, faktor lain turut mempengaruhi pengurangan masa keluaran, seperti autotest. Selepas setiap keluaran, kami mula menjalankan retrospektif. Supaya seluruh pasukan mempunyai idea tentang perkara baharu, perkara yang diubah, dan perkara yang telah dialih keluar. Malangnya admin tidak selalu datang kepada mereka, yelah, admin sibuk... Kepuasan kerja saya sebagai pembangun sudah pasti meningkat. Apabila anda boleh menyelesaikan hampir semua masalah dengan cepat dalam bidang kecekapan anda, anda berasa di atas. Kemudian, saya akan faham bahawa sedikit sebanyak kita memperkenalkan budaya devops, tidak sepenuhnya, sudah tentu, tetapi walaupun permulaan transformasi itu mengagumkan.

Cerita tiga
Memulakan. Seorang pentadbir, jabatan pembangunan kecil. Semasa ketibaan saya adalah sifar sepenuhnya, kerana... Saya tidak mempunyai akses ke mana-mana kecuali dari mel. Kami menulis kepada pentadbir dan meminta akses. Di samping itu, terdapat maklumat bahawa dia mengetahui tentang pekerja baru dan keperluan untuk mengeluarkan log masuk/kata laluan. Mereka memberikan akses daripada repositori dan VPN. Mengapa memberi akses kepada wiki, teamcity, rundesk? Perkara yang tidak berguna untuk seseorang yang dipanggil untuk menulis keseluruhan bahagian belakang. Hanya dari semasa ke semasa kami mendapat akses kepada beberapa alatan. Ketibaan itu, tentu saja, disambut dengan rasa tidak percaya. Saya cuba perlahan-lahan merasakan bagaimana infrastruktur projek berfungsi melalui sembang dan soalan utama. Pada asasnya saya tidak mengenali apa-apa. Pengeluaran adalah kotak hitam yang sama seperti sebelum ini. Tetapi lebih daripada itu, malah pelayan peringkat yang digunakan untuk ujian adalah kotak hitam. Kami tidak boleh melakukan apa-apa selain menggunakan cawangan dari Git di sana. Kami juga tidak boleh mengkonfigurasi aplikasi kami seperti fail .env. Akses untuk operasi sedemikian tidak diberikan. Anda perlu memohon untuk menukar baris dalam konfigurasi aplikasi anda pada pelayan ujian. (Terdapat teori bahawa pentadbir adalah penting untuk merasakan diri mereka penting dalam projek itu; jika mereka tidak diminta untuk menukar baris dalam konfigurasi, mereka tidak akan diperlukan). Nah, seperti biasa, bukankah ia mudah? Ini dengan cepat menjadi membosankan, selepas perbualan langsung dengan pentadbir, kami mendapati bahawa pembangun dilahirkan untuk menulis kod yang buruk, secara semula jadi adalah individu yang tidak cekap dan lebih baik menjauhkan mereka daripada pengeluaran. Tetapi di sini juga dari pelayan ujian, untuk berjaga-jaga. Konflik semakin memuncak. Tiada komunikasi dengan admin. Keadaan diburukkan lagi kerana dia bersendirian. Berikut adalah gambar biasa. Lepaskan. Fungsi tertentu tidak berfungsi. Kami mengambil masa yang lama untuk memikirkan apa yang berlaku, pelbagai idea daripada pembangun dilemparkan ke dalam sembang, tetapi pentadbir dalam keadaan sedemikian biasanya menganggap pembangun yang harus dipersalahkan. Kemudian dia menulis dalam sembang, tunggu, saya betulkan dia. Apabila diminta meninggalkan cerita dengan maklumat tentang masalahnya, kami menerima alasan toksik. Seperti, jangan letak hidung anda di tempat yang tidak sepatutnya. Pembangun mesti menulis kod. Keadaan apabila banyak pergerakan badan dalam projek melalui satu orang dan hanya dia mempunyai akses untuk melakukan operasi yang diperlukan oleh semua orang adalah amat menyedihkan. Orang seperti itu adalah kesesakan yang dahsyat. Jika idea Devops berusaha untuk mengurangkan masa ke pasaran, maka orang sedemikian adalah musuh paling teruk idea Devops. Malangnya, tirai ditutup di sini.

P.S. Selepas bercakap sedikit tentang pembangun vs pentadbir dalam sembang dengan orang, saya bertemu dengan orang yang berkongsi kesakitan saya. Tetapi ada juga yang mengatakan bahawa mereka tidak pernah menemui perkara seperti ini. Pada satu persidangan devops, saya bertanya kepada Anton Isanin (Alfa Bank) bagaimana mereka menangani masalah kesesakan dalam bentuk pentadbir, yang dia berkata: "Kami menggantikannya dengan butang." By the way podcast dengan penyertaan beliau. Saya ingin percaya bahawa terdapat ramai lagi pentadbir yang baik daripada musuh. Dan ya, gambar pada permulaan adalah surat-menyurat sebenar.

Sumber: www.habr.com