Saya baru-baru ini mengunjungi DevOpsForum 2019 yang diselenggarakan oleh Logrocon. Pada konferensi ini, para peserta mencoba menemukan solusi dan alat baru untuk interaksi bisnis dan spesialis yang efektif dalam pengembangan dan layanan teknologi informasi.
Konferensi ini sukses: benar-benar ada banyak laporan berguna, format presentasi yang menarik dan banyak komunikasi dengan para pembicara. Dan sangat penting bahwa tidak ada yang mencoba menjual saya apa pun, selain yang disalahkan oleh pembicara di konferensi besar.
Meremas dari pidato Raiffeisenbank, Alfastrakhovanie, pengalaman Mango Telecom dalam implementasi otomatisasi dan detail lainnya di bawah potongan.
Nama saya Yana, saya bekerja sebagai tester, saya terlibat dalam otomatisasi, serta DevOps dan saya suka pergi ke konferensi dan rapat. 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 memperhatikan program konferensi. Untuk tingkat yang lebih rendah saya melihat apa yang akan menjadi laporan, untuk tingkat yang lebih besar - untuk pembicara. Sekalipun laporan itu ternyata sangat teknologis dan menarik, bukan fakta bahwa Anda akan dapat menerapkan beberapa praktik terbaik dari laporan di perusahaan Anda. Dan kemudian Anda membutuhkan pembicara.
Cahaya di ujung pipa di Raiffeisenbank
Biasanya, saya pergi berburu untuk pembicara yang menarik di sela-sela. Di DevOpsForum 2019, seorang pembicara dari Raiffeisenbank, Mikhail Bizhan, memasuki bidang yang saya minati. Selama pidatonya, dia memberi tahu bagaimana mereka terus menanam tim mereka di DevOps, mengapa mereka membutuhkannya dan bagaimana menjual ide transformasi DevOps ke bisnis. Nah, secara umum, saya berbicara tentang cara melihat cahaya di ujung pipa.
Mikhail Bizhan, Direktur Otomasi di RaiffeisenbankSekarang perusahaan mereka tidak memiliki "DevOps." Artinya, dia benar, tetapi tidak di semua tim. Saat menerapkan DevOps, mereka bergantung pada kemauan tim baik dari sudut pandang insinyur tertentu, dan dari sudut pandang kebutuhan produk dan kematangan platform tempat produk ini dibangun. Misha memberi tahu cara menjelaskan kepada bisnis mengapa DevOps diperlukan.
Segmen perbankan memiliki beberapa pendorong pertumbuhan: biaya layanan dan perluasan basis klien. Meningkatkan biaya layanan bukanlah pendorong yang sangat baik, tetapi pertumbuhan basis pelanggan adalah sebaliknya. Jika pesaing menghasilkan produk yang secara objektif keren, semua pelanggan pergi ke sana, maka seiring waktu pasar akan menyamakan kedudukan. Karena itu, peluncuran produk baru di pasar dan kecepatan peluncurannya adalah hal utama yang dipandu oleh bank. Ini persisnya untuk apa DevOps, dan bisnis mengerti ini.
Catatan penting berikut: DevOps tidak selalu mengurangi waktu untuk memasarkan. DevOps tidak bisa bekerja sendiri, itu hanya bagian dari proses membuat dan meluncurkan produk di pasar dari pengembangan hingga produksi (dari kode ke klien). Tetapi segala sesuatu sebelum kode tidak memiliki hubungan langsung dengan DevOps. Artinya, pemasar dapat mempelajari pasar selama bertahun-tahun dan mengejar ketinggalan dengan pesaing sepanjang hidup mereka. Anda perlu cepat memahami apa yang dibutuhkan klien dan merencanakan implementasi fitur tertentu - seringkali ini tidak cukup bagi DevOps untuk bekerja dan perusahaan untuk mencapai tujuan. Oleh karena itu, pertama-tama, Raiffeisenbank setuju dengan bisnis bahwa perlu belajar cara menggunakan DevOps. Otomasi demi otomasi tidak akan banyak membantu dalam perjuangan untuk pelanggan baru.
Secara umum, Misha percaya bahwa DevOps harus dilaksanakan, tetapi dengan bijak. Dan Anda harus siap dengan kenyataan bahwa pada awal transformasi tim akan kehilangan produktivitas, itu akan menghasilkan lebih sedikit uang, tetapi kemudian akan menjadi kenyataan.
Tes Otomasi di Mango Telecom
Yegor Maslov dari Mango Telecom membuat laporan menarik lain untuk saya sebagai penguji. Presentasi itu disebut "Otomatisasi siklus tes penuh dalam tim SCRUM." Egor percaya bahwa DevOps diciptakan khusus untuk SCRUM, tetapi pada saat yang sama, memperkenalkan DevOps ke dalam tim SCRUM cukup bermasalah. Ini karena tim SCRUM selalu berjalan di suatu tempat, tidak ada waktu untuk terganggu oleh inovasi dan membangun kembali proses. Masalahnya juga terletak pada fakta bahwa SCRUM tidak menyiratkan sub-tim (tim penguji, tim pengembangan, dll.). Selain itu, dokumentasi diperlukan untuk mengotomatiskan proses yang ada, dan dalam SCRUM paling sering tidak ada dokumentasi sama sekali - “suatu produk lebih penting daripada semacam coretan”.
Setelah beralih ke SCRUM, penguji mulai berkonsultasi dengan pengembang tentang cara menguji fitur. Secara bertahap, volume fungsionalitas meningkat, dokumentasinya hilang, dan mereka mulai menangkap banyak bug dalam fungsionalitas di mana tidak ada jangkauan pengujian dan secara umum tidak lagi jelas siapa dan kapan mengujinya. Singkatnya - kebingungan dan terguncang. Kami memutuskan untuk beralih ke otomatisasi pengujian. Tapi kemudian ada kegagalan total. Mereka menarik spesialis outsourcing untuk otomatisasi yang menulis di tumpukan yang tidak diketahui oleh penguji reguler. Kerangka kerja autotest pasti berhasil, tetapi setelah agen outsourcing pergi, dia hidup selama dua minggu. Kemudian ada upaya untuk memperkenalkan swa-uji nomor dua. Itu dimulai dengan fakta bahwa segala sesuatu perlu dibangun di dalam perusahaan, dengan sendirinya (vektor yang tepat: menambah keahlian di dalam), dalam kerangka kerja SCRUM, dan dalam proses pembuatan dokumentasi. Tumpukan untuk otomatisasi harus sama dengan tumpukan produk (di sini saya akan mengarahkan plus, yah, jangan menguji proyek Anda dalam JavaScript dengan yang lain). Di akhir sprint, mereka mengatur demo tentang cara kerja autotest, dengan partisipasi seluruh tim (berguna). Dengan demikian, keterlibatan semua anggota tim dalam proses otomasi meningkat, serta kepercayaan pada autotest dan peluang bahwa autotest ini akan digunakan secara akurat (dan tidak akan dikomentari dalam sebulan karena kegagalan terus-menerus).
Omong-omong, mikrofon terbuka berfungsi di DevOpsForum 2019 - format yang sudah lama dikenal dan, menurut pendapat saya, berguna. Anda berjalan seperti itu, mendengarkan laporan, dan kemudian memutuskan bahwa ada baiknya membahas topik atau masalah dalam kerangka konferensi, dan berbagi pengalaman yang relevan dalam menyelesaikan masalah.
Saya juga memperhatikan bahwa panitia membuat aliran laporan singkat. Setiap laporan berlangsung tidak lebih dari 10 menit, lalu pertanyaan datang. Dengan demikian, Anda dapat membahas banyak topik sekaligus dan mengganggu pertanyaan untuk pembicara yang tertarik.
Di antara laporan-laporan itu, saya berjalan mengitari tribun mitra konferensi dan menarik / memenangkan banyak hal. Eh, aku suka razdatku!Pertanyaan meja bundar dan DevOps dengan Direktur Pengembangan Alfastrah
Ceri pada kue DevOpsForum 2019 bagi saya adalah sesi pleno selama satu jam dengan para ahli DevOps. Empat peserta diundang untuk menonton DevOps dari sudut yang berbeda: Anton Isanin (Alfastrakhovanie, Direktur Pengembangan), Naila Zamashkina (Lab Fintech, Direktur Operasi), Oleg Egorkin (Rostelecom, Agile-coach) dan Anton Martyanov (independen ahli, memandang DevOps dari perspektif bisnis).
Para ahli duduk lebih dekat dengan orang-orang dan itu dimulai: selama satu jam para peserta dari audiensi mengajukan pertanyaan mereka, dan para ahli itu kehabisan tenaga. Terkadang debat nyata muncul. Pertanyaannya sangat berbeda, misalnya: apakah para insinyur DevOps diperlukan sama sekali, mengapa mereka tidak dapat tumbuh dari administrator sistem, seandainya DevOps ditawarkan kepada semua orang, berapa nilainya, dan sebagainya.
Kemudian, saya berbicara dengan Anton Isanin secara pribadi. Kami membahas perlunya membawa budaya DevOps ke setiap rumah dan mengungkapkan sisi gelap dari transformasi DevOps.
Bayangkan bahwa semua orang berkumpul dan memutuskan bahwa DevOps diperlukan baik untuk produk maupun untuk bisnis dan tim. Bergegas memperkenalkan. Semuanya berhasil. Dihembuskan. DevOps membuat kami lebih dekat dengan klien, sekarang kami dapat dengan cepat memenuhi semua keinginannya. Sebagai hasilnya, kami memiliki divisi Ops besar dengan peraturan dan persyaratan yang ketat, dan itu terus-menerus mencari tahu cacat untuk produk, menciptakan banyak aplikasi. Selain itu, semua cacat datang dengan status "mendesak", bahkan jika klien tiba-tiba ingin mengecat tombol dengan warna kuning, bukan hijau. Proyek ini berkembang, jumlah rilis terus bertambah, dan dengan demikian jumlah cacat dan kesalahpahaman fungsi baru oleh pelanggan. Ops merekrut 10 orang lagi untuk mengimbangi cacat, dan pengembangan mempekerjakan 15 orang lagi untuk mengikutinya. Dan alih-alih memperkenalkan fitur baru, tim bekerja dengan SD tanpa akhir, menjelaskan fungsionalitas kepada pengguna dan mendukungnya. Akibatnya, baik Ops maupun pengembangan sedang bekerja, tetapi klien dan bisnis tidak bahagia: fitur-fitur baru macet. Ternyata DevOps tampaknya ada di sana, tetapi tampaknya tidak ada.
Mengenai perlunya menerapkan DevOps, Anton dengan tegas menyatakan bahwa ini secara langsung tergantung pada skala bisnis. Jika melayani satu klien per tahun membuat perusahaan itu bernilai satu miliar - DevOps tidak diperlukan (asalkan Anda tidak perlu melakukan perubahan baru pada klien ini secara rutin). Semuanya coklat. Tetapi jika bisnis tumbuh, lebih banyak pelanggan muncul, maka kita harus sudah patuh. Sebagai aturan, perusahaan tidak memiliki Op keren pada awalnya. Pertama kita melihat produk, dan baru setelah itu kita mengerti bahwa produk tersebut harus bekerja, Anda perlu melihat server, memantau pengiriman. Kemudian Ops muncul. Masih harus dipahami bahwa Ops, sebagai unit yang terpisah, akan mulai mengungkap banyak hambatan untuk pengembangan dan semua pengiriman akan mulai macet. Artinya, dalam hal ini, budaya DevOps sudah relevan, tetapi Anda tidak boleh melupakan sisi gelapnya.