Saya baru-baru ini menghadiri DevOpsForum 2019, yang diselenggarakan oleh Logrocon. Pada konferensi ini, para peserta mencoba mencari solusi dan alat baru untuk interaksi yang efektif antara bisnis dan pengembangan serta spesialis layanan teknologi informasi.
Konferensi ini sukses: banyak sekali laporan yang bermanfaat, format presentasi yang menarik dan banyak komunikasi dengan pembicara. Dan yang paling penting adalah tidak ada seorang pun yang mencoba menjual apa pun kepada saya, sesuatu yang menjadi kesalahan para pembicara di konferensi besar akhir-akhir ini.
Kutipan dari pidato Raiffeisenbank, Alfastrakhovanie, pengalaman Mango Telecom dalam mengimplementasikan otomatisasi dan detail lainnya.
Nama saya Yana, saya bekerja sebagai penguji, saya melakukan otomatisasi, serta DevOps, dan saya suka menghadiri konferensi dan pertemuan. Selama dua tahun terakhir, saya telah menghadiri konferensi Oleg Bunin (HighLoad++, TeamLead Conf), acara Jug (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
Pertama-tama, saya menarik perhatian pada program konferensi. Saya kurang memperhatikan isi laporannya, dan lebih banyak memperhatikan pembicara. Meskipun laporan tersebut ternyata sangat berteknologi dan menarik, bukan fakta bahwa Anda akan dapat menerapkan beberapa praktik terbaik dari laporan tersebut di perusahaan Anda. Dan kemudian Anda membutuhkan seorang pembicara.
Cahaya di ujung pipa di Raiffeisenbank
Biasanya saya berburu pembicara di sela-sela yang saya minati. Di DevOpsForum 2019, pembicara dari Raiffeisenbank, Mikhail Bizhan, menarik minat saya. Dalam pidatonya, dia berbicara tentang bagaimana mereka secara bertahap membuat tim mereka terpikat pada DevOps, mengapa mereka membutuhkannya, dan bagaimana menjual ide transformasi DevOps ke dalam bisnis. Secara umum, saya berbicara tentang cara melihat cahaya di ujung pipa.
Mikhail Bizhan, direktur otomasi di Raiffeisenbank
Sekarang mereka tidak memiliki “DevOps” di perusahaan mereka. Artinya, dia bekerja, tapi tidak di semua tim. Saat mengimplementasikan DevOps, mereka mengandalkan kesiapan tim, baik dalam hal teknisi spesifik, maupun dalam hal kebutuhan produk dan kematangan platform tempat produk ini dibangun. Misha menceritakan cara menjelaskan kepada bisnis mengapa DevOps diperlukan.
Segmen perbankan memiliki beberapa pendorong pertumbuhan: biaya layanan dan perluasan basis klien. Menaikkan biaya layanan bukanlah faktor pendorong yang baik, namun meningkatkan basis klien adalah kebalikannya. Jika pesaing merilis produk yang secara obyektif keren, semua pelanggan pergi ke sana, dan seiring berjalannya waktu, pasar akan melemah. Oleh karena itu, memperkenalkan produk baru ke pasar dan kecepatan pengenalannya menjadi hal utama yang menjadi fokus bank. Inilah gunanya DevOps, dan bisnis memahami hal ini.
Catatan penting berikutnya: DevOps tidak selalu mengurangi waktu pemasaran. DevOps tidak dapat bekerja sendiri, ini hanyalah bagian dari proses pembuatan dan membawa produk ke pasar mulai dari pengembangan hingga produksi (dari kode hingga pelanggan). Namun segala sesuatu sebelum kode tersebut tidak terkait langsung dengan DevOps. Artinya, pemasar dapat mempelajari pasar selama bertahun-tahun dan menghabiskan seluruh hidup mereka untuk mengejar pesaing. Penting untuk segera memahami apa yang dibutuhkan klien dan merencanakan implementasi fitur ini atau itu - seringkali hal ini tidak cukup agar DevOps dapat berfungsi dan perusahaan dapat mencapai tujuannya. Oleh karena itu, pertama-tama, Raiffeisenbank setuju dengan dunia bisnis bahwa perlu mempelajari cara menggunakan DevOps. Otomatisasi demi otomatisasi tidak akan banyak membantu dalam memperebutkan pelanggan baru.
Secara umum, Misha berpendapat bahwa DevOps perlu diterapkan, namun dengan bijak. Dan kita harus siap menghadapi kenyataan bahwa pada awal transformasi, produktivitas tim akan turun, pendapatannya akan lebih sedikit, tetapi kemudian hal itu akan dibenarkan.
Otomatisasi pengujian di Mango Telecom
Laporan menarik lainnya bagi saya sebagai tester diberikan oleh Egor Maslov dari Mango Telecom. Presentasinya berjudul “Otomasi siklus pengujian penuh dalam tim SCRUM.” Egor percaya bahwa DevOps diciptakan khusus untuk SCRUM, namun pada saat yang sama, memperkenalkan DevOps ke dalam tim SCRUM cukup bermasalah. Hal ini terjadi karena tim SCRUM selalu berjalan di suatu tempat, tidak ada waktu untuk teralihkan oleh inovasi dan membangun kembali proses. Permasalahannya juga terletak pada kenyataan bahwa SCRUM tidak melibatkan pemisahan sub-tim dalam tim (tim penguji, tim pengembangan, dan sebagainya). Selain itu, untuk mengotomatisasi proses yang ada, diperlukan dokumentasi, dan di SCRUM, seringkali tidak ada dokumentasi yang lengkap - “produk lebih penting daripada semacam tulisan.”
Setelah beralih ke SCRUM, penguji mulai berkonsultasi dengan pengembang tentang cara menguji fitur. Secara bertahap, volume fungsionalitas meningkat, tidak ada dokumentasi, dan mereka mulai menemukan banyak bug dalam fungsionalitas yang tidak tercakup dalam pengujian dan secara umum tidak lagi jelas siapa yang mengujinya dan kapan. Singkatnya - kebingungan dan kebimbangan. Kami memutuskan untuk beralih ke otomatisasi pengujian. Namun meski begitu, terjadi kegagalan total. Mereka mempekerjakan spesialis otomasi outsourcing yang menulis pada tumpukan yang tidak diketahui oleh penguji internal. Kerangka kerja untuk pengujian otomatis berhasil, tentu saja, tetapi setelah agen outsourcing pergi, hal itu berlangsung selama dua minggu. Berikutnya adalah upaya untuk memperkenalkan pengujian otomatis nomor dua. Ini dimulai dengan fakta bahwa segala sesuatu perlu dibangun di dalam perusahaan, sendiri (vektor yang tepat: membangun keahlian secara internal), dalam kerangka SCRUM, dan membuat dokumentasi dalam prosesnya. Tumpukan untuk otomatisasi harus sama dengan tumpukan produk (di sini saya menambahkannya, jangan uji proyek JavaScript Anda dengan yang lain). Di akhir sprint, mereka melakukan demo tentang cara kerja autotest dengan seluruh tim (bermanfaat). Dengan demikian, keterlibatan seluruh anggota tim dalam proses otomatisasi meningkat, serta kepercayaan terhadap autotest dan kemungkinan autotest ini pasti akan digunakan (dan tidak akan dikomentari dalam sebulan karena kegagalan terus-menerus).
Omong-omong, di DevOpsForum 2019 ada mikrofon terbuka - format pidato yang sudah lama dikenal dan, menurut saya, berguna. Anda berkeliling seperti ini, mendengarkan laporan, dan kemudian memutuskan bahwa di konferensi itu ada baiknya mendiskusikan topik atau masalah tertentu, berbagi pengalaman yang relevan dalam memecahkan masalah tersebut.
Saya juga memperhatikan bahwa penyelenggara membuat laporan singkat. Setiap laporan berdurasi tidak lebih dari 10 menit, dilanjutkan dengan pertanyaan. Dengan cara ini Anda dapat membahas banyak topik sekaligus dan mengajukan pertanyaan kepada pembicara yang Anda minati.
Di sela-sela presentasi, saya berjalan mengelilingi stan mitra konferensi dan mencuri/memenangkan banyak barang. Eh, saya suka selebarannya!
Masalah meja bundar dan DevOps dengan direktur pengembangan di Alfastrakhovanie
Bagi saya, hal yang paling menarik dalam DevOpsForum 2019 adalah sesi pleno selama satu jam dengan para pakar DevOps. Empat peserta sesi diundang untuk melihat DevOps dari sudut berbeda: Anton Isanin (Alfastrakhovanie, direktur pengembangan), Nailya Zamashkina (Fintech Lab, direktur operasi), Oleg Egorkin (Rostelecom, Agile coach) dan Anton Martyanov (pakar independen, melihat DevOps dari sudut pandang bisnis).
Para ahli duduk lebih dekat dengan orang-orang dan kemudian hal-hal mulai terjadi: selama satu jam penuh, peserta dari penonton mengajukan pertanyaan mereka, dan para ahli menerima tanggapannya. Terkadang terjadi perdebatan nyata. Pertanyaannya sangat berbeda, misalnya: apakah para insinyur DevOps diperlukan, mengapa mereka tidak dapat dilatih sebagai administrator sistem, apakah DevOps harus ditawarkan kepada semua orang, apa nilainya, dan sebagainya.
Kemudian saya ngobrol pribadi dengan Anton Isanin. Kami mendiskusikan perlunya menghadirkan budaya DevOps ke setiap rumah dan mengungkap sisi gelap transformasi DevOps.
Bayangkan semua orang berkumpul dan memutuskan bahwa DevOps dibutuhkan baik oleh produk maupun oleh bisnis dan tim. Ayo kita terapkan. Semuanya berhasil. Kami menghela napas. DevOps telah mendekatkan kami dengan klien, kini kami dapat dengan cepat memenuhi semua keinginannya. Hasilnya, kami memiliki departemen Operasi yang besar dengan peraturan dan persyaratan yang ketat, dan departemen tersebut terus-menerus menemukan cacat pada produk dan menimbulkan banyak permintaan. Selain itu, semua cacat diberi status "mendesak", meskipun klien tiba-tiba ingin mewarnai tombol tersebut dengan warna kuning, bukan hijau. Proyek ini berkembang, jumlah rilis meningkat dan, dengan demikian, jumlah cacat dan kesalahpahaman tentang fungsi baru oleh klien. Ops mempekerjakan 10 orang lagi untuk terus melaporkan kerusakan, dan pengembangan mempekerjakan 15 orang lagi untuk menutupnya. Dan alih-alih memperkenalkan fitur-fitur baru, tim bekerja dengan SD tanpa akhir, sambil menjelaskan fungsionalitasnya kepada pengguna dan dukungan. Hasilnya, baik Operasi maupun pengembangan berfungsi, namun klien dan bisnis tidak puas: fitur-fitur baru terhenti. Ternyata DevOps sepertinya ada, tapi sepertinya tidak ada.
Soal perlunya penerapan DevOps, Anton dengan tegas menyatakan bahwa hal itu bergantung langsung pada skala bisnisnya. Jika melayani satu klien dalam setahun menghasilkan miliaran dolar bagi perusahaan, DevOps tidak diperlukan (asalkan Anda tidak perlu meluncurkan perubahan baru pada klien ini secara rutin). Semuanya dilapisi coklat. Namun jika bisnisnya berkembang dan semakin banyak klien yang bermunculan, maka Anda perlu mematuhinya. Biasanya, pada awalnya tidak ada Operasi keren di perusahaan. Pertama kita memotong produknya, dan baru kemudian kita memahami bahwa agar produk dapat berfungsi, kita perlu mengawasi server dan memantau persediaan. Saat itulah Ops muncul. Perlu dipahami bahwa Ops, sebagai divisi terpisah, akan mulai memberikan banyak hambatan terhadap pengembangan dan semua pengiriman akan mulai terhenti. Artinya, dalam hal ini budaya DevOps sudah relevan, namun kita tidak boleh melupakan sisi gelapnya.
Sumber: www.habr.com