Saya baru-baru ini menghadiri DevOpsForum 2019, dihoskan oleh Logrocon. Pada persidangan ini, para peserta cuba mencari penyelesaian dan alat baharu untuk interaksi berkesan antara perniagaan dan pembangunan serta pakar perkhidmatan teknologi maklumat.
Persidangan itu berjaya: terdapat banyak laporan yang berguna, format persembahan yang menarik dan banyak komunikasi dengan penceramah. Dan amat penting bahawa tiada sesiapa cuba menjual apa-apa kepada saya, sesuatu yang telah dilakukan oleh penceramah di persidangan besar kebelakangan ini.
Petikan daripada ucapan Raiffeisenbank, Alfastrakhovanie, pengalaman Mango Telecom dalam melaksanakan automasi dan butiran lain di bawah pemotongan.
Nama saya Yana, saya bekerja sebagai penguji, saya melakukan automasi, serta DevOps, dan saya suka pergi ke persidangan dan pertemuan. Sepanjang dua tahun yang lalu, saya telah menghadiri persidangan Oleg Bunin (HighLoad++, TeamLead Conf), acara Jug (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
Pertama sekali, saya menarik perhatian kepada program persidangan. Saya kurang melihat tentang laporan itu, dan lebih kepada penceramah. Walaupun laporan itu ternyata sangat berteknologi dan menarik, bukan fakta bahawa anda akan dapat menggunakan beberapa amalan terbaik daripada laporan itu dalam syarikat anda. Dan kemudian anda memerlukan pembesar suara.
Cahaya di hujung saluran paip di Raiffeisenbank
Biasanya, saya memburu penceramah di luar yang menarik minat saya. Di DevOpsForum 2019, penceramah dari Raiffeisenbank, Mikhail Bizhan, menarik minat saya. Semasa ucapannya, beliau bercakap tentang bagaimana mereka secara beransur-ansur membuat pasukan mereka tertarik pada DevOps, mengapa mereka memerlukannya, dan cara menjual idea transformasi DevOps kepada perniagaan. Nah, secara umum, saya bercakap tentang cara melihat cahaya di hujung saluran paip.
Mikhail Bizhan, pengarah automasi di Raiffeisenbank
Kini mereka tidak mempunyai "DevOps" dalam syarikat mereka. Iaitu, dia bekerja, tetapi tidak dalam semua pasukan. Apabila melaksanakan DevOps, mereka bergantung pada kesediaan pasukan, baik dari segi jurutera khusus dan dari segi keperluan produk dan kematangan platform di mana produk ini dibina. Misha memberitahu cara untuk menerangkan kepada perniagaan mengapa DevOps diperlukan.
Segmen perbankan mempunyai beberapa pemacu pertumbuhan: kos perkhidmatan dan pengembangan pangkalan pelanggan. Meningkatkan kos perkhidmatan bukanlah pemacu yang sangat baik, tetapi mengembangkan pangkalan pelanggan adalah sebaliknya. Jika pesaing mengeluarkan produk yang menarik secara objektif, semua pelanggan pergi ke sana, kemudian dari masa ke masa pasaran keluar. Oleh itu, memperkenalkan produk baharu ke pasaran dan kepantasan pengenalannya adalah perkara utama yang diberi tumpuan oleh bank. Inilah tujuan DevOps, dan perniagaan memahami perkara ini.
Nota penting seterusnya: DevOps tidak selalu mengurangkan masa ke pasaran. DevOps tidak boleh berfungsi secara bersendirian, ia hanyalah sebahagian daripada proses mencipta dan membawa produk ke pasaran daripada pembangunan kepada pengeluaran (daripada kod kepada pelanggan). Tetapi segala-galanya sebelum kod tidak berkaitan secara langsung dengan DevOps. Iaitu, pemasar boleh mengkaji pasaran selama bertahun-tahun dan menghabiskan seluruh hidup mereka mengejar pesaing. Adalah perlu untuk memahami dengan cepat apa yang pelanggan perlukan dan merancang pelaksanaan ciri ini atau itu - selalunya inilah yang tidak mencukupi untuk DevOps berfungsi dan syarikat mencapai matlamatnya. Oleh itu, pertama sekali, Raiffeisenbank bersetuju dengan perniagaan bahawa perlu mempelajari cara menggunakan DevOps. Automasi demi automasi tidak akan banyak membantu dalam perjuangan untuk pelanggan baharu.
Secara umum, Misha percaya bahawa DevOps perlu dilaksanakan, tetapi dengan bijak. Dan kita mesti bersedia untuk fakta bahawa pada permulaan transformasi produktiviti pasukan akan menurun, ia akan mendapat lebih sedikit wang, tetapi kemudian ia akan dibenarkan.
Automasi ujian di Mango Telecom
Satu lagi laporan menarik untuk saya sebagai penguji telah diberikan oleh Egor Maslov dari Mango Telecom. Pembentangan itu dipanggil "Automasi kitaran ujian penuh dalam pasukan SCRUM." Egor percaya bahawa DevOps dicipta khusus untuk SCRUM, tetapi pada masa yang sama, memperkenalkan DevOps ke dalam pasukan SCRUM agak bermasalah. Ini berlaku kerana pasukan SCRUM sentiasa berjalan di suatu tempat, tidak ada masa untuk terganggu oleh inovasi dan membina semula proses. Masalahnya juga terletak pada fakta bahawa SCRUM tidak melibatkan pemisahan sub-pasukan dalam pasukan (pasukan ujian, pasukan pembangunan, dan sebagainya). Selain itu, untuk mengautomasikan proses sedia ada, dokumentasi diperlukan, dan dalam SCRUM, selalunya tiada dokumentasi sepenuhnya - "produk itu lebih penting daripada beberapa jenis penulisan."
Selepas bertukar kepada SCRUM, penguji mula berunding dengan pembangun tentang cara menguji ciri. Secara beransur-ansur, jumlah kefungsian meningkat, tiada dokumentasi, dan mereka mula menangkap banyak pepijat dalam fungsi yang tidak diliputi oleh ujian dan secara umum tidak lagi jelas siapa yang mengujinya dan bila. Secara ringkas - kekeliruan dan goyah. Kami memutuskan untuk beralih kepada automasi ujian. Tetapi pada masa itu terdapat kegagalan sepenuhnya. Mereka mengupah pakar automasi penyumberan luar yang menulis pada timbunan yang tidak diketahui oleh penguji dalaman. Sudah tentu rangka kerja untuk autotest berfungsi, tetapi selepas penyumber luar pergi, ia berlangsung selama dua minggu. Seterusnya adalah percubaan untuk memperkenalkan autotesting nombor dua. Ia bermula dengan hakikat bahawa segala-galanya perlu dibina dalam syarikat, sendiri (vektor yang betul: membina kepakaran secara dalaman), dalam rangka kerja SCRUM, dan mencipta dokumentasi dalam proses itu. Timbunan untuk automasi hendaklah sama dengan timbunan produk (di sini saya menambahnya, jangan uji projek JavaScript anda dengan apa-apa lagi). Pada penghujung larian pecut, mereka melakukan demo tentang cara autotest berfungsi dengan seluruh pasukan (membantu). Oleh itu, penglibatan semua ahli pasukan dalam proses automasi meningkat, serta kepercayaan terhadap autotest dan peluang autotest ini pasti akan digunakan (dan tidak akan diulas dalam masa sebulan kerana kegagalan berterusan).
Ngomong-ngomong, di DevOpsForum 2019 terdapat mikrofon terbuka - format ucapan yang sudah lama diketahui dan, pada pendapat saya, berguna. Anda berjalan-jalan seperti ini, mendengar laporan, dan kemudian memutuskan bahawa pada persidangan itu adalah berbaloi untuk membincangkan topik atau masalah tertentu, berkongsi pengalaman yang relevan dalam menyelesaikan masalah itu.
Saya juga perasan bahawa penganjur membuat aliran laporan ringkas. Setiap laporan berlangsung tidak lebih daripada 10 minit, diikuti dengan soalan. Dengan cara ini anda boleh membincangkan banyak topik sekaligus dan bertanya soalan kepada penceramah yang menarik minat anda.
Di antara pembentangan, saya berjalan di sekitar gerai rakan persidangan dan mencuri/menang banyak barangan. Oh, saya suka edaran itu!
Isu meja bulat dan DevOps dengan pengarah pembangunan di Alfastrakhovanie
Ais pada kek DevOpsForum 2019 bagi saya ialah sesi pleno selama sejam bersama pakar DevOps. Empat peserta sesi telah dijemput untuk melihat DevOps dari sudut yang berbeza: Anton Isanin (Alfastrakhovanie, pengarah pembangunan), Nailya Zamashkina (Fintech Lab, pengarah operasi), Oleg Egorkin (Rostelecom, jurulatih Agile) dan Anton Martyanov (pakar bebas, melihat DevOps dari sudut perniagaan).
Pakar duduk lebih dekat dengan orang ramai dan kemudian perkara mula berlaku: selama sejam, peserta daripada penonton bertanya soalan mereka, dan pakar mengambil rap. Kadang-kadang berlaku perdebatan sebenar. Soalan-soalannya sangat berbeza, contohnya: adakah jurutera DevOps diperlukan sama sekali, mengapa mereka tidak boleh dilatih sebagai pentadbir sistem, sekiranya DevOps ditawarkan kepada semua orang, apakah nilainya, dan sebagainya.
Kemudian, saya bercakap dengan Anton Isanin secara peribadi. Kami membincangkan keperluan untuk membawa budaya DevOps ke setiap rumah dan mendedahkan sisi gelap transformasi DevOps.
Bayangkan semua orang berkumpul dan memutuskan bahawa DevOps diperlukan oleh produk dan oleh perniagaan dan pasukan. Mari kita laksanakannya. Semuanya berjaya. Kami menghembus nafas. DevOps telah membawa kami lebih dekat dengan pelanggan, kini kami dapat memenuhi semua kehendaknya dengan cepat. Akibatnya, kami mempunyai jabatan Ops yang besar dengan peraturan dan keperluan yang ketat, dan ia sentiasa menemui kecacatan pada produk dan mewujudkan banyak permintaan. Lebih-lebih lagi, semua kecacatan diberikan status "mendesak", walaupun pelanggan secara tidak sengaja mahu mewarnakan butang kuning dan bukannya hijau. Projek ini semakin berkembang, bilangan keluaran semakin meningkat dan, oleh itu, bilangan kecacatan dan salah faham fungsi baharu oleh pelanggan. Ops mengupah 10 orang lagi untuk bersaing dengan melaporkan kecacatan, dan pembangunan mengupah 15 lagi untuk bersaing dengan menutupnya. Dan bukannya memperkenalkan ciri baharu, pasukan bekerja dengan SD yang tidak berkesudahan, menerangkan fungsi kepada pengguna dan sokongan pada masa yang sama. Akibatnya, kedua-dua Ops dan pembangunan berfungsi, tetapi pelanggan dan perniagaan tidak berpuas hati: ciri baharu tersekat. Ternyata DevOps nampaknya wujud, tetapi ia nampaknya tidak wujud.
Mengenai keperluan untuk melaksanakan DevOps, Anton dengan jelas menyatakan bahawa ini secara langsung bergantung pada skala perniagaan. Jika memberi perkhidmatan kepada satu pelanggan setahun membawa syarikat itu satu bilion, DevOps tidak diperlukan (dengan syarat anda tidak perlu melancarkan perubahan baharu kepada pelanggan ini dengan kerap). Semuanya diliputi coklat. Tetapi jika perniagaan berkembang dan lebih ramai pelanggan muncul, maka anda perlu mematuhinya. Sebagai peraturan, tiada Ops hebat dalam syarikat pada mulanya. Mula-mula kami memotong produk, dan barulah kami memahami bahawa untuk produk itu berfungsi, kami perlu memerhatikan pelayan dan memantau bekalan. Ketika itulah Ops wujud. Perlu difahami bahawa Ops, sebagai bahagian yang berasingan, akan mula meletakkan banyak halangan kepada pembangunan dan semua penghantaran akan mula terhenti. Iaitu, dalam kes ini, budaya DevOps sudah relevan, tetapi kita tidak boleh melupakan sisi gelapnya.
Sumber: www.habr.com