Artikel terakhir telah menyebabkan banyak kemarahan, saya pikir artikel ini tidak akan disukai oleh banyak orang lagi, di dalamnya saya akan menjelaskan bagaimana pelanggan melihat seorang insinyur DevOps.
Semakin banyak waktu berlalu, semakin saya mendengar bahwa "ini adalah tugas" devups ", permintaan ke database ingin menyetel devups, tebak bagaimana dan dengan dependensi apa perangkat lunak akan menuju pembuat kode - devups, evpn + bgp + ipsec + geo dns + otorisasi jaringan dengan sertifikat - devups, memperbaiki kesalahan arsitektur dan muncul dengan opsi bloodless - devups, mengubah pg_dump biasa menjadi replikasi sinkronis - devups, menjadi psikoanalis untuk stasiun layanan / CEO dan tim - devups.
Tren menarik lainnya adalah load balancer k8s + untuk bersin apa pun. Belum lama ini saya bahkan ditawari untuk meletakkan load balancer di database, mungkin rata-rata beban akan turun dan disk akan kurang dimuat .... K8 umumnya merupakan topik terpisah, Anda dapat menulis 2-3 artikel tentang mitos yang terkait dengannya.
Semakin banyak, Anda dapat mendengar dari bisnis bahwa pengembang dan insinyur semakin mabuk, bahwa Sberbank telah menciptakan gelembung sabun, dan keajaiban akan terjadi, dan kami akan mulai bekerja sebagai orang biasa selama 60-80 ribu dari para senior. Di daerah, tentu saja, ini sudah ada, tetapi semuanya menyedihkan di sana, tetapi di sini mereka sudah bermimpi untuk semua kota kecuali Moskow.
Jauh lebih menyenangkan dari bisnis yang sama untuk mendengarkan betapa malasnya semua orang, cerita tentang betapa tidak bergunanya karyawan, dan bahwa Anda perlu mencari cara untuk tidak merencanakan pekerjaan, arsitektur, memikirkan masa depan, tetapi menampar kode berkualitas rendah secepat kilat, karena kemudian devup "berskala horizontal ", Ya, kami memiliki 1 kueri dalam database, biaya 15% dari kapasitas perangkat keras, dan 5 kueri - runtuh, lalu apa? Penskalaan horizontal tanpa alokasi sumber daya akan menyelamatkan kita !!! - kebenaran tidak ditentukan bagaimana. Apalagi jika database cukup bengkok dalam arsitektur, misalnya default PostgreSQL atau Elasticsearch.
Gunakan teknologi sebagaimana dimaksud? Tidak, itu membosankan. Merencanakan arsitektur, skema data, dan pemrosesannya - mengapa mahal dan lambat. Tapi apa yang harus dilakukan? Ada solusinya - pekerjakan seorang devups dan salahkan dia atas semua dosa berat proyek Anda, jangan lupa menambahkan - semuanya bekerja tepat sebelum Anda datang. Dan log berbohong, semuanya bekerja !!!
Semakin sering saya melihat proyek-proyek yang cukup menarik dan menjanjikan sekarat, bahkan pada tahap permulaannya, hanya karena permainan politik. Saya berkomunikasi dengan RM, yang telah terhalang selama enam bulan untuk menjual produk yang dapat menghasilkan miliaran rubel per tahun bagi perusahaan, tetapi mereka terus-menerus berbicara di rodanya. Setiap orang mencari cara untuk melakukan pengembangan tanpa mengeluarkan biaya untuk itu, dan metodologi DevOps semakin dianggap sebagai cara untuk membuang produk yang tidak berfungsi ke dalam produksi, dan menutupi tiang dengan wadah, penyeimbang, dan rintisan, bahkan jika ini mengarah ke peringkat rendah dan sejumlah besar negativitas, yang utama adalah menghemat pengembangan.
Seperti yang diperlihatkan oleh survei di artikel sebelumnya, bagi mayoritas pengunjung habr, pengusaha mencoba memasang beberapa lubang dengan 1 orang. Wajar saja, tanpa mengimbangi kewajiban tersebut. Tetapi masalahnya adalah bisnis itu sendiri menderita sebagai akibatnya. Karena upah rendah dan produktivitas tenaga kerja yang tinggi dalam kaitannya dengan dukungan keuangan dan teknis, bisnis tersebut bertahan, jika, dengan manajemen seperti di CIS, mereka mencoba berbisnis di Jepang atau Amerika Serikat, bisnis itu akan bangkrut sejak lama.
Banyak metodologi yang kami terima dari negara maju telah sepenuhnya terdistorsi. Misalnya, Agile, Scrum, DevOps - semua 3 metodologi memerlukan perubahan signifikan dalam proses bisnis agar dapat berfungsi, tetapi manajemen di CIS belum siap untuk ini, ia berharap dapat menggabungkan kebiasaan lama dan metodologi modern, kami berada di puncak dengan cara lama, dan Anda berada dalam cara yang modern dan efektif Jauh di bawah. Tidak masuk akal untuk menerapkan semua 3 metodologi dari bawah, keberadaan kartu, laporan harian, rencana selama 2 minggu dan rilis untuk setiap baris kode tidak berarti Anda telah menerapkan metodologi ini, itu berarti Anda telah memperkenalkan proses pelaporan tambahan yang hanya membantu menemukan penyebab dan alasannya. untuk manajemen senior. Hanya lebih sulit bagi proyek dan orang-orang yang mulai bekerja dalam kondisi seperti itu untuk melaksanakan rencana mereka, karena jumlah laporan bertambah secara signifikan lebih banyak,dibandingkan jika tidak.
Sekarang ada cukup banyak artikel dan pidato oleh manajer TI aneh yang sudah menawarkan untuk membayar hasil, hampir seperti sebelumnya untuk baris kode, menghilangkan waktu dari pekerjaan untuk memikirkan implementasi, mengingat itu adalah 30-40 menit, dan kemudian hanya menulis kode. Pada saat yang sama, beri kami waktu 2-3 minggu untuk memikirkan dan menghitung biaya dan risiko untuk keputusan manajemen ... Akibatnya, kami semakin dihadapkan pada kenyataan bahwa kualitas produk pasti menurun, tentu saja, ini bukan hanya masalah industri TI, tetapi di industri kami sangat akut, karena kegagalan kemudian disalahkan pada programmer yang, seperti "menyia-nyiakan 180 juta rubel," saya Saya telah melihat 4 proyek yang, sebagai hasil dari proses ini, tidak memenuhi tugasnya, tetapi telah menghabiskan 1 miliar rubel atau lebih,tetapi akibatnya, spesialis IT yang malas menjadi bersalah dan lebih banyak pelaporan dan prosedur pengaturan mulai memperbaiki situasi. Untuk memastikan fungsi pengawasan, manajer tambahan dipekerjakan, dan gaji untuk spesialis TI dikurangi. Jumlah keputusan yang kita buat sendiri menurun, dan tanggung jawab serta akuntabilitas meningkat, yang mengarah pada masalah yang lebih besar.
Anda perlu menarik garis tanggung jawab dengan jelas, dan meminimalkannya, jika tidak, Anda hanya menjadi korban dalam permainan politik apa pun.
Di artikel berikutnya saya akan menulis lebih banyak tentang mengapa DevOps dan Agile, yang diterapkan dari bawah, tidak akan pernah berguna.
DevOps atau bagaimana kita kehilangan gaji dan masa depan industri TI, bagian kedua
All Articles