Pada 7 Desember, konferensi
DevOpsDays Moscow yang ketiga diselenggarakan oleh komunitas DevOps Moskow dengan dukungan Mail.ru Cloud Solutions. Selain laporan praktisi DevOps terkemuka, peserta dapat menghadiri Ceramah Petir yang memotivasi, lokakarya, dan mengobrol di ruang terbuka.
Kami mengumpulkan wawasan penting dari enam presentasi dan melakukan wawancara dengan beberapa pembicara untuk mengetahui apa yang tertinggal dari laporan.
Di dalam:
- Baruch Sadogursky, JFrog: "Biarkan perangkat lunak mengalir dari vendor ke pengguna, seperti cairan"
- Pavel Selivanov, Southbridge: "Dev dan Ops memiliki satu tugas bersama - untuk membuat produk yang berfungsi"
- Vladimir Utratenko, Grup Ritel X5: “DevOps in Enterprise adalah pengembangan tanpa rasa sakit dan kebakaran”
- Sergey Puzyrev, Facebook: "Production Engineer menangani layanan secara keseluruhan: sehingga pengguna dan pengembang merasa baik"
- Mikhail Chinkov, AMBOSS: "Satu unit tidak dapat mengikuti jalur DevOps, seluruh perusahaan harus mengikutinya"
- Penggemar Rosbank DevOps: “1000 hari untuk mengimplementasikan DevOps di perusahaan berdarah”
1. Baruch Sadogursky, JFrog: "Biarkan perangkat lunak mengalir dari vendor ke pengguna, seperti cairan"
Kegagalan saat memperbarui perangkat lunak terjadi setiap jam dan untuk semua orang. Berikut ini hanya satu kisah menakutkan dari pidato tersebut: Knight Capital kehilangan $ 440 juta per jam setelah pembaruan yang gagal.
Baruch berbicara tentang pola-pola pembaruan terus-menerus DevOps yang akan membantu menghindari kegagalan dan kebencian pengguna:
Kembalikan lokal - menjaga versi perangkat lunak sebelumnya pada perangkat untuk mundur jika terjadi sesuatu. Ini akan melindungi Anda jika semuanya begitu buruk sehingga Anda tidak dapat mengirim tambalan melalui udara.
Pembaruan udara terus menerus lebih baik. Ini akan berbeda, seperti halnya dengan pengembang Jaguar: karena ada bug dalam sistem rem yang tidak dapat diperbarui melalui udara, maka perlu menarik kembali mobil yang dijual. Itu menyakitkan dan mahal.
Pembaruan berkelanjutan - memperbarui perangkat lunak secara terus-menerus segera setelah fitur baru siap. Dengan pembaruan langka, fitur dikelompokkan, pembaruan kritis dapat menunggu yang tidak kritis. Seperti di Tesla, pembaruan yang seharusnya memperbaiki pengereman acak sedang menunggu agar permainan catur diperbarui.
Penempatan otomatis - ganti orang dengan mesin, karena orang tidak tahu bagaimana melakukan tindakan rutin.
Pembaruan yang sering - membantu mengembangkan kebiasaan dan menghilangkan rasa takut. Pembaruan langka berubah menjadi acara darurat.
Pengetahuan tentang kondisi perangkat - pembaruan pengujian, bukan pemasangan dari awal. Ini penting, karena pembaruan dapat berperilaku berbeda tergantung pada kondisi perangkat.
Canary rilis - meluncurkan pembaruan untuk sejumlah kecil pengguna dan menonton. Ini mengurangi kerusakan jika terjadi kesalahan.
Pembaruan tanpa aksesibilitas - biarkan pelanggan hanya memperhatikan fitur baru, dan jangan tetap tanpa layanan selama beberapa minggu hingga Anda meluncurkan pembaruan.
Kami berbicara dengan Baruch Sadogursky tentang bagaimana pandangan DevOps berbeda dalam IT Rusia dan Barat, apakah Cloud akan segera melakukan segalanya untuk kami dan apakah semua layanan perangkat lunak akan meluncur ke skema aaS - lihat wawancara:
2. Pavel Selivanov, Southbridge: "Dev dan Ops memiliki satu tugas bersama - untuk membuat produk yang berfungsi"
Menerapkan Kubernetes tidak akan membantu mencapai DevOps, dan bahkan sebaliknya - itu dapat merusak segalanya. Pavel mengatakan mengapa teknologi (bahkan yang paling keren) tidak dapat menyelesaikan semua masalah Anda:
Kompleksitas proyek telah melampaui kode . Sebelumnya, ada aplikasi yang kompleks: interaksi dalam proyek dan pengembangan kompleks, tetapi struktur sederhana - administrator dikerahkan, semuanya berfungsi. Kami beralih ke layanan mikro: setiap layanan adalah aplikasi sederhana, komunikasi menggunakan protokol standar dan pengembangan cepat, tetapi struktur proyek menjadi lebih rumit. Kompleksitas proyek dengan arsitektur microservice belum hilang - telah bergerak melampaui kode. Sekarang insinyur DevOps bertanggung jawab untuk itu.
Pengembang tidak ingin perubahan setelah implementasi DevOps . Akibatnya, alur kerja dengan Kubernetes terus terlihat seperti membuang tugas dari Dev ke Ops melalui dinding, tetapi tidak metaforis lagi - Git menjadi tembok seperti itu. Pengembang meletakkan kode di sana dan berfungsi seperti sebelumnya, dan admin memiliki Kubernetes, CI / CD dan yang lainnya.
Namun, pengembang harus menerima perubahan . Situasi ketika pengembang tidak tahu apa yang dilakukan administrator, dan administrator tidak tahu apa yang terjadi dengan pengembang, menciptakan masalah.
Jika pengembang tidak mengubah apa pun, mereka tidak menyadari bahwa pekerjaan aplikasi adalah tanggung jawab mereka - berbagai trik teknis tidak akan berfungsi.
Dengan munculnya DevOps dan Kubernetes, banyak yang akan berubah dalam pengembangan. Dev harus kompeten dalam Ops, dan sebaliknya. Para spesialis ini memiliki keterampilan khusus mereka sendiri, tetapi mereka harus menyadari pekerjaan masing-masing. Dev dan Ops harus berteman sebelum menerapkan Kubernetes, jika tidak, Anda akan mendobrak apa yang ada.
Pavel Selivanov berbicara tentang apa yang akan terjadi pada Kubernetes dalam 5 tahun dan tentang apa yang akan membangun tumpukan teknologi untuk startup modern - lihat wawancara:
3. Vladimir Utratenko, Grup Ritel X5: "DevOps in Enterprise adalah pengembangan tanpa rasa sakit dan kebakaran"
Perusahaan datang ke transformasi DevOps ketika mereka menyadari bahwa pembangunan terlalu lambat dan tidak memenuhi kenyataan, mereka memiliki keinginan untuk berkembang lebih baik dan meluncurkan lebih cepat.
Vladimir memberi tahu bagaimana ini terjadi, dan apa masalahnya:
- Pertama, perusahaan mempekerjakan insinyur DevOps. Ini adalah Senior System Administrator, ia terlibat dalam penyebaran rilis ke produksi, standarisasi lingkungan pengembangan, menyiapkan infrastruktur, mendeteksi dan memperbaiki berbagai masalah, otomatisasi proses dan tugas teknis lainnya.
- Kemudian satu insinyur DevOps tidak lagi cukup, dan perusahaan mempekerjakan tim DevOps. Ini adalah pusat kompetensi, yang mengatur upaya para insinyur yang berbeda, memungkinkan Anda untuk memfokuskan mereka dalam satu arah.
- Faktanya, tim insinyur DevOps dan tim DevOps adalah antipatterns dari transformasi DevOps. Karena DevOps adalah tentang praktik dan budaya, di samping itu, ada implementasi DevOps di perusahaan teknologi (SRE, Teknik Produksi).
Apa yang harus dilakukan Menyewa tim DevOps sementara untuk membantu menerapkan transformasi DevOps akan melakukan praktik, menumbuhkan budaya pembangunan dan budaya teknologi.
Ketika sebuah bisnis memasuki permainan dan berinvestasi di DevOps, beberapa skenario dimungkinkan: semuanya akan berantakan saat lepas landas; akan tetap sebagai SRE / Teknik Produksi atau Embedded Ops; akan pindah ke BizOps ketika proses mengandalkan metrik bisnis.
Vladimir Utratenko memberi tahu kami bagaimana DevOps "berdarah" di perusahaan sebenarnya dan bagaimana praktik diterapkan di dalam toko ritel besar - lihat wawancara:
4. Sergey Puzyrev, Facebook: "Engineer Produksi menangani layanan secara keseluruhan: sehingga pengguna dan pengembang merasa baik"
Facebook adalah perusahaan besar dengan banyak komponen, server, orang, pusat data. Meskipun ukurannya sangat besar, sangat cepat - pengembang dapat menggelar layanan berkali-kali sehari. Facebook juga berkembang pesat, dan ini bukan hanya tentang peningkatan jumlah pengguna dan server, jumlah pengembang juga meningkat, yang memperumit prosesnya.
Sergey memberi tahu apa yang dilakukan Engineer Produksi di Facebook:
- Insinyur Produksi banyak mengkodifikasi, harus memiliki pengetahuan sistem: sistem operasi, sistem file, database, jaringan dan sejenisnya. Harus memiliki pengalaman dengan sistem terdistribusi dan Keandalan Rekayasa, yaitu, dalam mendukung keandalan produk. Ia harus siap dipanggil, yaitu siap untuk dipanggil kapan saja.
- Production Engineer berbeda dari Software Engineer dalam keterampilan canggih dalam operasi, tetapi, pada kenyataannya, adalah subspesies dari Software Engineer. Kode Insinyur Perangkat Lunak lebih banyak, mereka mungkin memiliki keterampilan tambahan terkait, misalnya, untuk pemrosesan data. Di Facebook, spesialis seperti itu juga harus siap siaga, yang bagi banyak orang merupakan kejutan yang tidak menyenangkan.
- Piramida kebutuhan Insinyur Produksi di perusahaan dimulai dengan memonitor server dan siklus hidup mereka, yaitu, menerima perangkat keras baru, mengaturnya, menjalankannya. Tingkat berikutnya adalah sama pada tingkat layanan: layanan pemantauan dan siklus hidupnya. Kemudian muncul skala dan pemantauan lanjutan. Mereka beralih ke autoscaling setelah siklus hidup layanan otomatis. Dan pada akhirnya, Anda perlu melakukan tuning agar penskalaan efektif, perusahaan menghemat uang dan sumber daya.
5. Mikhail Chinkov, AMBOSS: "Satu unit tidak dapat mengikuti jalur DevOps, seluruh perusahaan harus mengikutinya"
Michael percaya bahwa DevOps adalah pengembangan berkelanjutan. Anda tidak dapat memperkenalkan alat apa pun dan berhenti di sana. Masalah apa yang mencegah perusahaan menjadi DevOps dan bagaimana menerapkan praktik?
Perbedaan dalam memahami DevOps . Para devon kanonik, sebagaimana para penginjil melihatnya, bersandar pada 5 pilar:
- budaya - fokus pada orang dan kolaborasi;
- otomatisasi - delegasi rutin ke alur kerja;
- lean - penekanan pada pengiriman nilai kepada pengguna;
- berbagi - berbagi pengetahuan terus menerus;
- metrik dan mendapatkan umpan balik dengan bantuan mereka.
Perusahaan biasanya hanya fokus pada otomatisasi dan pengiriman nilai kepada pengguna. Tetapi budaya, berbagi pengetahuan, dan metrik DevOps, yang dengannya Anda dapat melacak perkembangan, berjalan di pinggir jalan.
Masalah DevOps standardisasi . Tujuan produk berbeda untuk semua perusahaan, mereka tidak dapat distandarisasi. Keadaan DevOps dalam perusahaan tergantung pada perusahaan itu sendiri, tetapi banyak yang tidak memahami ini dan percaya bahwa itu cukup untuk menyewa seorang insinyur DevOps.
Mengapa kita belum DevOps? Ada dua masalah utama. Dalam Enterprise - lambatnya perkembangan organisasi, sulitnya mengubah vektor di kepala ribuan karyawan. Di startup, ada kekurangan sumber pengetahuan, masalah dengan alokasi sumber daya untuk transformasi.
Tahapan pengembangan DevOps di perusahaan :
- yang pertama adalah infrastruktur di cloud, tetapi tidak ada yang tahu cara kerjanya, kecuali satu atau dua admin;
- yang kedua - infrastrukturnya transparan dan mudah dipahami oleh semua insinyur, tetapi prosesnya tidak berjalan;
- yang ketiga - insinyur secara mandiri meluncurkan dan memperbaiki layanan langsung;
- yang keempat - insinyur, jika mereka mau, akan berkontribusi pada infrastruktur inti, kode transparan di cloud, penyebaran tombol.
Skema yang ideal - setiap orang memiliki akses yang sama ke infrastruktur, semua insinyur mendapatkan akses ke produk dan memahami apa yang mereka lakukan.
Menutup semua gestalt budaya dan teknis, transformasi DevOps perusahaan akan mempertimbangkan umpan balik akun dari metrik bisnis dan metrik platform.
6. Penggemar DevOps dari Rosbank: “1000 hari untuk mengimplementasikan DevOps di perusahaan berdarah”
Yuri Bulich, Dina Maltseva, Eugene Pankov dari Rosbank menceritakan bagaimana mereka sampai di DevOps dalam tiga tahun. Ada dua tujuan: untuk memecahkan masalah spesifik dalam tim tertentu dan mengimplementasikan alat yang terpusat.
Inilah hasil yang dicapai:
Hasil untuk tim produk : perakitan 30 kali lebih cepat, instalasi 6 kali lebih cepat, penghematan hingga 30% pada siklus penuh. Kami mendapat kesempatan untuk memutar tombol menjadi produktif
Hasil untuk tim platform : perakitan dan pemasangan 10 kali lebih cepat, jumlah instalasi meningkat 87%, cakupan dengan autotest 46%. Tim Integrasi Berhenti Menjadi Hambatan
Jadi, bagaimana menerapkan praktik DevOps di perusahaan berdarah?
Pertama, perkenalkan proyek percontohan : pilih tim, putuskan bagaimana mengimplementasikan arsitektur dan pilih alat. Kami memilih alat dengan lisensi terbuka, dengan instalasi di bank dan keahlian dalam bekerja dengannya. Di Rosbank, bersama dengan platform DevOps, cloud pribadi digunakan, dan ini membantu pada awalnya. Di cloud, dimungkinkan untuk mendapatkan sumber daya yang diperlukan dengan tombol dalam 15 menit, sebelumnya proses seperti itu bisa memakan waktu seminggu.
Di bank dan perusahaan lain, Anda harus mengatasi pembatasan dengan tim keamanan informasi terlebih dahulu dan menemukan solusi yang akan memungkinkan Anda untuk menerapkan perubahan.
Setelah uji coba, solusi yang sukses harus ditingkatkan .
- Penting untuk "meluruskan" conveyor sebanyak mungkin, menghilangkan tautan yang tidak perlu, untuk menyoroti penyedia nilai, dan menghapus komponen yang tersisa. Intermediate adalah antipatterns. Misalnya, di Rosbank, sejumlah tim tidak memiliki pengembangan internal, hanya eksternal yang tersisa. Hal ini menyebabkan munculnya tim DevOps yang berdedikasi, yang menyediakan transfer kode dari pengembang eksternal ke yang internal. Masalahnya diselesaikan dengan mengintegrasikan pengembangan eksternal ke dalam CI / CD sehingga mereka tidak hanya akan mentransfer kode dari diri mereka sendiri ke bank, tetapi juga bertanggung jawab atas keberhasilannya.
- Elemen-elemen praktik DevOps dimasukkan dalam model kematangan, alat terdaftar, dan fitur-fitur bekerja dengan pemasok eksternal diperhitungkan - di masa depan ini membantu dengan cepat memotong simpanan tugas ketika diterapkan dalam tim baru.
- Diperlukan tata kelola dalam bentuk kontrol lunak dan rekomendasi. DevOps Handbook berfungsi dengan baik - ini adalah serangkaian karakteristik organisasi dan instrumental yang membantu tim menggunakan platform dengan benar.
- Perlu segera memperhatikan budaya, maka banyak perubahan akan lebih cepat dan mudah. Menumbuhkan komunitas internal, mengadakan pertemuan, lokakarya teknis, pelatihan, kegiatan yang menyenangkan. Ini memberi hasil: orang-orang berbagi praktik mereka, melihat siapa yang telah melakukan apa, tahu ke mana harus berpaling, ada hype dan persaingan sehat di dalam perusahaan.
- Tidak masuk akal untuk bekerja dengan mereka yang tidak terlibat dalam proses, dengan tim yang tidak matang, lebih baik berinvestasi dalam tim yang tertarik dan orang yang setia.
- Solusi yang dipilih harus nyaman bagi para insinyur yang menggunakannya.
- Pengembangan eksternal bukan pemblokir, Anda juga dapat menerapkan praktik di sana, yang utama adalah bahwa tim itu sendiri memiliki keinginan.
Sedikit lebih baik
Daftar buku yang harus dibaca oleh mereka yang berada di DevOps, dari Alexander Chistyakov, vdsina.ru:
- Irina Yakutenko "Keinginan dan pengendalian diri".
- Daniel Kahneman "Berpikir, Cepat dan Lambat."
- Barbara Oakley "A Mind for Numbers".
- Maxim Dorofeev "Teknik Jedi."
- Viktor Frankl "Pencarian Manusia untuk Makna".
Tetap disini
Kami juga menyukai DevOps. Ikuti pengumuman seri
@DevOps dan @Kubernetes, serta acara Cloud Solutions Mail.ru lainnya, di saluran Telegram kami:
t.me/k8s_mail