Bagaimana saya tidak pergi ke London, tetapi berpartisipasi dalam London DevOps Enterprise Summit





KTT DevOps Enterprise rutin diadakan di London dari 23 hingga 25 Juni 2020. "Di London" dapat ditulis dalam tanda kutip, karena pandemi melakukan tugasnya dan konferensi diadakan secara online. Ada hal-hal buruk di sini (jaringan masih sangat menderita) dan hal-hal baik: Anda dapat mengambil jeda antara laporan dari semua orang, Anda dapat menyisihkan beberapa hari untuk mempelajari laporan yang menarik bagi Anda, dan fokus - ini sangat berguna ... Baru-baru ini saya menghadiri pertemuan "di Chelyabinsk", hari berikutnya - "di Novosibirsk", dan beberapa hari kemudian - di California: secara fisik akan sangat sulit untuk melakukan ini. Tentu saja, ada rekaman, tetapi rasa meluangkan waktu untuk belajar tampaknya membantu belajar.



Format laporan konferensi telah mengakar di Habré, dan keinginan untuk berkembang dalam kondisi ketika Anda duduk di rumah telah menjadi sangat kuat (Anda harus melakukan sesuatu) - dan di sini muncul pertanyaan: ada banyak konferensi ... bagaimana melihat semua yang ingin Anda lihat?



Dan di sini saya berpikir bahwa saya dapat mencoba membuat laporan tentang konferensi dalam format yang berbeda - bukan untuk memberi tahu tentang apa laporannya (untuk ini saya memposting "siaran teks langsung" terpisah dari laporan yang saya dengarkan), tetapi untuk menulis artikel yang merangkum kesimpulan dan tren saat ini, akan menunjukkan ke mana harus mencari pengetahuan terbaru.





Apakah yang dimaksud dengan DevOps Enterprise Summit? Apa bedanya dengan konferensi lainnya?



Setiap artikel tentang konferensi DevOps, tentu saja, harus dimulai dengan diskusi tentang apa itu DevOps - dan, tentu saja, semua orang bosan karenanya. Karena itu, saya akan mencoba untuk ringkas!



Faktanya, setiap orang yang berdebat cenderung menyetujui setidaknya satu hal - bahwa "devops adalah serangkaian praktik yang memfasilitasi pengiriman perangkat lunak dan manajemen infrastruktur." Satu-satunya perbedaan adalah bahwa satu kelompok (dan paling sering ini adalah "admin") mengatakan "diskusi praktik harus praktis", dan kelompok kedua (dan ini adalah pengembangan dan, paling sering, manajemen dalam pengembangan) percaya bahwa "ini adalah filosofi dan metodologi ".



Saya akan mengambil risiko menimbulkan kemarahan untuk "penyederhanaan", tetapi pada intinya: untuk pengembangan, pengenalan metode dan kemampuan "admin" mengubah proses pengembangan itu sendiri secara ideologis dan mengubah DevOps menjadi Agile baru - ketika kita mendengar tentang konferensi manajerial tentang DevOps, kita mendengar tentang perubahan dalam metodologi pengembangan. Dan DevOps Enterprise Summit adalah salah satu konferensi yang berguna untuk "admin": ada juga laporan yang lebih dekat dengan teknis.



Jadi, DevOps Enterprise Summit telah diselenggarakan sejak 2014, dan diselenggarakan oleh IT Revolution dengan pendiri Gene Kim, yang dikenal banyak orang dari buku "Project Phoenix". IT Revolution adalah penerbit yang telah meluncurkan serangkaian buku tentang DevOps dan tautannya ke Agile. Kenapa Harus Enterprise? Ini adalah poin yang sangat penting.



Menerapkan metodologi lincah di perusahaan kecil itu mudah: di perusahaan multi-orang, mereka kemungkinan besar sudah ada sejak awal - Anda hanya perlu memanggil mereka seperti itu. Dengan ribuan perusahaan, puluhan ribu orang, semuanya jauh lebih rumit. Ada sejumlah besar proses di dalamnya, dibangun sehingga raksasa ini terus bergerak, dan ini dapat dibandingkan dengan kapal besar. Ketika sebuah kapal melakukan perjalanan melintasi lautan dari satu daratan ke daratan lain, ia memenuhi perannya, tetapi kapal tidak dapat mengubah rute dan mengubah arah dalam waktu sesingkat mungkin - ini membutuhkan waktu, terutama dalam bisnis teknologi. Sebuah perusahaan muda hanya beberapa dapat membangun prototipe dalam hitungan hari bahwa sebuah perusahaan ribuan akan membangun selama bertahun-tahun - jika tidak berubah.Oleh karena itu, perusahaan besar ingin mengubah dan menggunakan metode "muda", tetapi mereka perlu memahami cara untuk tidak mengganggu proses mereka. Saya telah memberikan contoh di artikel lain: di Excel 1900 dianggap sebagai tahun kabisat, dan ini dilakukan untuk kompatibilitas dengan versi Lotus 1-2-3, yang memiliki bug seperti itu. Versi-versi ini dirilis pada tahun 80-an - dan pertanyaannya adalah: haruskah kompatibilitas ini dipertahankan? Sejauh mana bug diizinkan dalam pendekatan "kami akan memperbaikinya nanti" ketika Anda menginstal perangkat lunak di bank pada server yang umumnya terputus dari Internet? Bagaimana Anda bisa mempertahankan fleksibilitas yang sama? Ini adalah tentang konferensi itu.Versi-versi ini dirilis pada tahun 80-an - dan pertanyaannya adalah: haruskah kompatibilitas ini dipertahankan? Sejauh mana bug diizinkan dalam pendekatan "kami akan memperbaikinya nanti" ketika Anda menginstal perangkat lunak di bank pada server yang umumnya terputus dari Internet? Bagaimana Anda bisa mempertahankan fleksibilitas yang sama? Ini adalah tentang konferensi itu.Versi-versi ini dirilis pada tahun 80-an - dan pertanyaannya adalah: haruskah kompatibilitas ini dipertahankan? Sejauh mana bug diizinkan dalam pendekatan "kami akan memperbaikinya nanti" ketika Anda menginstal perangkat lunak di bank pada server yang umumnya terputus dari Internet? Bagaimana Anda bisa mempertahankan fleksibilitas yang sama? Ini adalah tentang konferensi itu.



Format



Setiap konferensi berusaha mencari cara untuk online, dan ini menarik. Dalam DOES, berikut ini dapat dicatat:



  • Laporan masih dibagi dengan trek, pemirsa dapat beralih di antara trek dalam proses.
  • Laporan dicatat sebelum hari konferensi, untuk menghindari masalah teknis dengan siaran, pembicara selama laporan berada di saluran kendur dan berkomunikasi dengan audiens. Ini mungkin hal paling menarik yang saya pelajari dari organisasi. Solusinya kontradiktif - di satu sisi, interaktif menghilang, di sisi lain, lebih banyak waktu untuk pertanyaan (dan lebih banyak peluang bagi pembicara untuk menjawab lebih banyak pertanyaan). Namun, misalnya, saya terutama mendengarkan laporan dan tidak ingin beralih ke diskusi, jadi saya datang di akhir, ketika ada sedikit waktu tersisa dan pembicara baru datang ke laporan berikutnya.
  • , -, .
  • , , , , « », - , , , .






DevOps Dojo. . , . SRE- Uptime community, , ? Dojo — , , . DevOps- Target, , , , , , , . . youtu.be/1FMktLCYukQ
  • Swiss Re — , 156 , DevOps- . , « ». «» — «» CEO, , .. , , , Gartner-, 76% DevOps- «, ». . — , . , «» DevOps- — . . , , : Hermes Germany GmbH , CIO, « », «» .
  • , — . State of Devops, Gene Kim Accelerate.
  • , , DevOps And Modernization 2.0 (CSG) Scott Prugh — DevOps . , — , : Cobol-, 3,7 IBM High Level Assembler Java ! : .


Buku-buku yang disebutkan layak dibaca:

Tim Topologi Beraksi , Percepat: Membangun dan Memperbesar Organisasi Teknologi Berkinerja Tinggi .



Dan saya sedikit lebih teratur daripada blog di sini, saya menjalankan saluran telegram saya sendiri , berlangganan.



All Articles