Tim pengembang dapat secara longgar digabungkan dan bekerja dalam arah yang berbeda, tidak mengetahui dan tidak ingin menggunakan DevOps. Dalam artikel hari ini, kita akan berbicara tentang bagaimana praktik DevOps dapat terdistorsi dan diubah sehingga dapat diterapkan di perusahaan dengan peraturan, kebijakan, dan kebiasaan masyarakat yang telah lama ada.



Materi ini didasarkan pada laporan dialog oleh Sergey Berdnikov (Mahkota Emas) dan Artem Kalichkin (CFT) dari konferensi Oktober DevOops 2017 . Di bawah transkrip video dan teks laporan.




Sergey: Saya adalah kepala departemen operasi di perusahaan kami. Artem dan saya memulai revolusi kecil-evolusi. Semuanya dimulai dengan revolusi, sekarang telah memasuki tahap evolusi.



Artem: Perusahaan telah beroperasi di pasar keuangan sejak 1992. Pekerjaan itu terdiri dari dua bagian utama. Bagian pertama adalah pengembangan perangkat lunak, Core Banking, akuntansi perbankan dan sebagainya. Di sini kami bertindak sebagai vendor: kami mengembangkan dan menjual Anda sebuah kotak, dan Anda menyebarkan dan mengoperasikannya.

Bagian kedua adalah layanan pemrosesan. Di sini kami menyediakan layanan baik secara langsung kepada individu atau melalui mitra kami. Ini adalah jaringan perdagangan besar, bank, dan peserta lain di pasar jasa keuangan. Di sini kami menyusun siklus penuh dari ide hingga pengembangan, implementasi, dan operasi lebih lanjut.

Kami bekerja dengan Sergey di bagian pemrosesan perusahaan kami. Tentang bagaimana kami sampai pada cerita dengan DevOps dalam pemrosesan ini, kami akan menceritakannya.

Apa itu

Sergey: Warisan kami sepenuhnya perbankan. Perusahaan awalnya membuat produk perbankan, masing-masing, semuanya akrab: seluruh infrastruktur SPARC saja, pusat data sendiri, seluruh inti ditulis dalam Oracle. PL / kode SQL, banyak hal - tidak mudah untuk mengukur.

Kami hanya melakukan penskalaan secara vertikal: kami membeli sepotong besi yang kuat, menggunakannya sampai menjadi usang, menggantinya dengan yang baru dan yang lama dibawa ke panggung.

Juga menulis banyak kode di Jawa. Kami memesan melalui cadangan hangat: ada pusat data, dan seluruh struktur yang disalin - switch, server, semua dalam satu, baut ke baut.



Di sini Anda dapat melihat bagaimana keseluruhan struktur terlihat dari sudut pandang proses. Ada Dev teknis direktorat yang terpisah, kemudian Firewall dengan api. Berikutnya adalah IT terpusat, yang terlibat dalam penghapusan, penyebaran dan sebagainya. Artinya, Devs menulis instruksi besar, dan Operasi TI dibagi menjadi tiga divisi:

• Administrator terapan yang terlibat dalam penyebaran. Mereka tidak memiliki root, ada pengguna di mesin, mereka bisa menjalankan instruksi - ini disebut kode Monkey.
• Administrator Unix yang bisa dan tahu cara mengkonfigurasi, menambah perangkat keras, dan sebagainya.
• Ada spesialis basis data individual. Dan karena basis data adalah tujuan utama kami, esensi keberadaan kami untuk waktu yang lama, banyak proses terjadi di sana.

Artem: DevOps belum ada di sini pada tahap ini, kami bekerja sesuai dengan peraturan, yang tidak disukai oleh Sergey.

Sergey: Saya bergabung dengan tim administrator yang diterapkan dan saya ingat apa "masa-masa indah" itu. Kami bisa membuat satu aplikasi selama tiga minggu. Sebuah aplikasi masuk, mereka menemukan beberapa jenis kesalahan di dalamnya dan membatalkannya, percaya bahwa orang bodoh itu sendiri tidak dapat menulis aplikasi. Dan pengetahuan yang diperlukan untuk penulisan aplikasi yang benar ada bersama saya.

Kemudian orang-orang berlari dalam sehari: "Dan apa yang kita tulis salah?" Saya menjelaskan bahwa di suatu tempat mereka tidak memberi plus atau minus, mereka lupa koma. Mereka menulis aplikasi, saya memberikan semacam keahlian tentang cara bekerja di Oracle, dan mengirimkannya lebih lanjut ke DBA, di mana orang-orang yang terlatih khusus yang tahu bagaimana memenuhi aplikasi ini duduk.

Dan mereka juga bekerja dengan saya, mereka berkata: "Mengapa Anda tidak menunjukkan indikator utama di sini, bukankah Anda menulis tanda titik koma?" Aplikasi dibatalkan, siklus dimulai lagi. Sekarang memalukan, tapi apa yang harus dilakukan, sebelum bekerja dengan cara ini.

Artem: Lalu kami mulai berubah. Benar-benar ada banyak aplikasi. Ketika Sergey bergabung dengan tim kami, ia adalah hasil dari evolusi dan transformasi kecil. Saya adalah penulis dari sejumlah besar peraturan untuk berbagai jenis aplikasi, karena saya harus bertahan hidup. Secara umum, seluruh transformasi kami terjadi bukan karena hype atau mode, tetapi karena kebutuhan untuk menyelesaikan masalah tertentu.

Misalnya, perubahan konfigurasi menyebabkan fakta bahwa pertarungan saya pecah dan tidak berfungsi dengan benar. Saya mengetahui hal ini dalam satu hari atau pada malam hari: kebetulan pada pukul enam malam mereka menggulung sesuatu, dan sampai pukul tiga pagi semua ini bekerja dengan tidak benar.

Ada instalasi versi sebelumnya yang tidak ada yang akan pergi dan tidak membahas apa yang harus dilakukan jika terjadi kesalahan. Instruksi pemasangan multi-halaman yang terkenal dan terkenal dikirimkan kepada semua orang secara harfiah setengah jam sebelum dimulainya pekerjaan dalam operasi. Itu perlu untuk menyelesaikan sesuatu, dan pada saat itu kami menemukan solusi - implementasi adaptif dari proses ITIL.

Kami mulai memeriksa apakah semuanya bergulir dengan benar setelah gulungan ke pertempuran, apakah layanan dan indikator utama bekerja dengan normal. Kami mulai berkencan sebelum menginstal versi. Dan kemudian, pada kenyataannya, adalah awal dari DevOps, ketika tim pengembangan, yang mengirimkan kit distribusi, mulai setidaknya bertemu dengan tim operasi, membahas apa yang akan terjadi dalam kerja malam.

Sergey: Dan ada sesuatu untuk didiskusikan: kami memiliki empat halaman instruksi instalasi - menjalankan perintah, menjalankan rencana. Hampir mustahil untuk menulis tanpa kesalahan. Kami terus bersumpah di antara pengembangan yang kami tulis salah, membacanya, dan hal-hal seperti itu. Rapat terkadang berubah menjadi neraka.

Artem: Kami mencoba untuk pindah dengan aplikasi ke Confluence, karena tidak nyaman untuk mentransmisikannya di Word - dimungkinkan untuk membentuk sesuatu yang salah. Dalam Confluence, mereka selalu berencana untuk mengunggah versi saat ini dengan semua perubahan.

Kami memasukkan sepotong kode untuk bergulir ke pertempuran. Confluence mengunyah meta-markup, mengeluarkan sesuatu yang salah, admin mengambil kode, yang berubah menjadi mie dan mulai bekerja dengannya - itu adalah bencana.

Kami menyadari bahwa tidak peduli seberapa sesat dengan instruksi halaman, semua ini berubah menjadi omong kosong, tidak peduli bagaimana itu dibingkai.

Ada prasyarat penting untuk waktu henti yang lama di malam hari, yang menyebabkan lepas landas setelah pemasangan yang buruk, ke kusen, dan sejumlah besar konflik antara pengembangan dan operasi.

• Banyak kesalahan manusia dalam mentransmisikan perubahan;
• Konstan mencari yang bersalah;
• Tingkat penghapusan modul baru hingga 3 minggu;
• Titik kegagalan tunggal (hanya penskalaan vertikal), kurangnya penyeimbangan;
• Downtime yang direncanakan selama pembaruan selama 2 jam.

Latar Belakang Transformasi

Sergey: Ada banyak perubahan, kami terus-menerus mengacau. Setiap minggu kami berkumpul, dikutuk, tenang. Proses ini diulangi selamanya, mereka mencari yang bersalah: "Ini semua pengembang yang menulis kode melengkung, bahkan modul Java tidak dapat ditransmisikan."

Artem: Tetapi para pengembang berpikir bahwa ini adalah hal-hal yang mendasar: kesalahan dalam log hilang - aturlah, cari di google dan pahami apa yang perlu diperbaiki di konfigurasi.

Sergey: Mereka juga merilis produk baru untuk waktu yang sangat lama. Ini hanya terkait secara struktural: mereka membuat permintaan untuk kami, kami harus membuat permintaan untuk membuat pengguna di server, lalu membuat skema. Kemudian sepakbola dimulai dengan aplikasi. Pengembang mengeluarkan modul, tetapi kami tidak dapat menggunakannya, kami memiliki segalanya sesuai dengan peraturan.

Kami juga menetapkan waktu yang sangat lama. Instruksi sangat besar, saat Anda membaca, saat Anda melakukannya, gulungan membutuhkan waktu sekitar dua jam. Tindakan itu sendiri tidak selesai dalam sedetik.

Artem: Ada juga tindakan rutin, misalnya, 30 modul Java. Dalam semua ada konfigurasi, di setiap konfigurasi Anda harus masuk dan membuat perubahan. Pertama, Anda bisa menjadi gila untuk membuat perubahan yang sama: Anda membenci diri sendiri dan seluruh umat manusia. Kedua, kemungkinan membuat kesalahan pada konfigurasi ke-25 menjadi sangat tinggi.

Sergey: Saya ingat bagaimana saya mendapat tawaran untuk mengukur secara horizontal. Dan kami memiliki 150 modul dengan konfigurasi berbeda: jika kesalahan ada dalam satu versi konfigurasi, mereka akan menempatkan saya yang kedua, dan saya akan membuat kesalahan di dalamnya. Bagaimanapun, kita bukan robot.

Artem: Downtime terjadwal dari waktu pembaruan 2 jam adalah salah satu faktor penting mengapa kami mulai mencari solusi, bagaimana cara menghindarinya.

Faktanya adalah bahwa kami menyediakan layanan keuangan, layanan pemrosesan. Kami bekerja di luar negeri. Saat itu, mereka sudah bekerja di 11 zona waktu, pada 2013 kami hanya memiliki satu jam windows, ketika menggunakan layanan ini minimal, jumlah panggilan klien diminimalkan, tenang datang, dan sesuatu bisa dilakukan.

Dengan syarat, kami bisa melakukan pekerjaan dari satu jam hingga dua malam. Dua jam lebih dari jendela ini. Kami sedang mendekati bencana, jika bukan karena transformasi, karena sekarang kami secara fisik tidak memiliki jendela.

Jawaban untuk semua masalah ini saya punya ide, upaya untuk mencari tahu apa itu DevOps.

Pada saat itu, kolega kami datang dengan HighLoad, saya sibuk dengan implementasi CMBD, karena saya perlu agar konfigurasi tidak rusak dan setidaknya saya bisa mengelola sesuatu. Dia mendengarkan laporan Sasha Titov, yang berbicara tentang beberapa Chef. Tampaknya juga manajemen konfigurasi

Pada 2013, saya membaca semuanya tentang itu, saya memutuskan bahwa beberapa sampah bukanlah yang saya butuhkan. Saya perlu mengontrol, dan mereka memaksa kode untuk menulis di sana. Namun, situasinya tidak berubah, masalah menumpuk dan saya memaksa diri saya untuk duduk di rumah dan mulai menyelesaikan masalah. Saya pikir ada sesuatu dalam hal ini, semacam keselamatan.

Dan kemudian saya menemukan postulat dan nilai-nilai bahwa kita harus memiliki lingkungan yang sama, skrip roll-out dan pembaruan yang sama, bahwa kita harus memeriksa skenario ini, dimulai dengan lingkungan pengujian.

Ada kesempatan untuk meminimalkan instruksi dan tindakan manual, dan untuk mengotomatiskan segala sesuatu sebanyak mungkin tidak hanya dengan skrip bash yang berbeda, di mana admin lain akan mematahkan kakinya nanti.

Saat itulah saya datang dengan ide ini, dengan deklarasi pertama tentang apa yang ingin saya terima. Ini adalah dokumen 2013, yang pertama dibuat di perusahaan tentang DevOps.

Sergey: Ini adalah ide kunci: untuk mengurangi kecepatan penghapusan modul baru, untuk mengurangi jumlah kesalahan selama penghapusan ke pertempuran. Artinya, ada tujuan khusus yang ingin kami capai pada tahap pertama rilis rilis baru.



Ada banyak argumen yang menentangnya. Sebagai contoh, ketakutan bahwa otomatisasi akan menghancurkan segalanya: itu berfungsi secara tidak masuk akal, menakutkan untuk mengeksekusi kode orang lain, ini adalah layanan hebat, orang-orang mendapatkan uang melalui kita. Tidak serius.

Selanjutnya bergabung dengan penjaga. Mereka berjalan melalui kami secara penuh: semacam panggung identik! Dan mereka memiliki gambaran dunia yang sempurna: pada flash drive, mentransfer versi, kami akan menandatanganinya dengan kunci PGP, dan semuanya akan baik-baik saja - layanan yang sempurna. Kami bekerja dengan mereka begitu lama untuk mencapai akhir, hanya berkat kegiatan proyek kami melakukan sesuatu.

Artem: Di sini kita mulai dari nilai: di sinilah kita kehilangan uang, yang sederhana ini tidak bisa diterima.

Orang-orang dan saya datang dengan cara untuk meminimalkan kerugian ini. Apakah Anda memiliki opsi yang lebih baik? Jika tidak, tetap diam, jika Anda mengkritik dan menawarkan. Tidak ada yang ditawarkan? Lalu kita coba.

Ada proses persuasi dan pemaksaan: kami menyarankan menggunakan ide-ide kami pada sejumlah sistem.

Sergey: Kami diminta untuk menuliskan semua risiko, bagaimana kami akan melepaskannya. Itu perlu untuk berkoordinasi dengan orang-orang yang bisa kehilangan uang. Juga, programmer mengatakan: "Kami menulis semacam kode, kami biasa mengirimkan zip secara normal, kami menulis instruksi, dan beberapa jenis kode lain untuk ditulis demi penghapusan ?!"

Artem: “Saya menulis kode aplikasi logika bisnis, saya menggunakan kerangka kerja untuk meminimalkan bagian kode yang tidak perlu. Dan Anda meminta lebih banyak kode untuk ditulis. Ambil dan ambil, pada akhirnya ”- dialog semacam itu ada di awal. Namun demikian, semua ini secara bertahap berhasil melalui demonstrasi dan kepercayaan.



Sergey: Dalam iterasi pertama, kami membuat banyak keputusan penting dalam hal struktur perusahaan kami dan dalam hal teknologi. Pertama-tama, kami menerapkan manajemen Konfigurasi. Ini menyelamatkan kami dari kesulitan mengeluarkan konfigurasi yang salah dengan instruksi 10 halaman A4.

Kemudian operasi mulai tenggelam, dan administrator aplikasi pindah ke direktorat teknis dengan pengembang. Itu memberi perasaan perintah, perasaan siku. Kami mulai memahami bahwa kami membuat produk, dan tidak memenuhi aplikasi yang tidak dapat dipahami dengan keinginan untuk menolaknya - ada tujuan khusus.

Kerja tim menarik ketika Anda duduk di sebelah orang, ketika Anda melihat bagaimana mereka bekerja, ketika mereka melihat bagaimana kami bekerja. Kami bahkan melakukan dialog antara tim: ini adalah percikan pertama dari DevOps nyata. Tidak ada teknologi, tidak ada teknologi baru. Dari sudut pandang teknologi, kami berpikir bahwa tidak ada yang akan berakar sama sekali, kami bekerja secara berbeda, di dunia lain.

Ide pertama adalah menulis Manajemen Konfigurasi sendiri, ada banyak pengembang. Kemudian kami mengingat semua yang kami tulis sendiri, dan menolak - kami semua gagal.

Artem: Saya akan memperbaiki rekan saya. Sergey salah: semua yang kami tulis bekerja dengan sempurna di bidang terapan kami, di mana kami kuat. Dan ketika mereka mencoba menulis beberapa laba-laba mereka untuk secara otomatis membangun CMDB atau semacam sistem pemantauan yang ditulis sendiri untuk mengendalikan logika bisnis - ya, inilah sistem kelas lain.

Pada tahap ini, ternyata admin aplikasi pindah dari departemen TI ke departemen teknis kami. Seperti kata Sergey, mereka mulai merasakan semua nilai bisnis, dasar karena hal-hal yang bersifat dagang.

Kami mendapat kesempatan untuk membayar mereka bonus proyek untuk pencapaian, itu cukup memotivasi. Ketika mereka memulai dialog, penghapusan modul dikurangi dari tiga minggu menjadi satu minggu atau lebih, dan beberapa kemajuan bahkan berjalan tanpa otomatisasi yang mendalam.



Sergey: Pada saat ini, jika kami tidak memahami sesuatu dengan aplikasi tersebut, kami meminta pengembang untuk datang: "Mari kita memutuskan bersama dan menulis bagaimana suara aplikasi tersebut".

Artem: Dan pada struktur komando yang kondisional ini, kami mulai beralih ke teknologi.

Sergey: Sekarang kami akan memberi tahu Anda bagaimana kami memilih sistem. Cukup menarik. Pertama-tama, kami mencoba Chef, untuk satu alasan sederhana - kami tahu seorang guru yang tahu Chef. Kemudian kami mencoba Wayang, karena pada waktu itu Oracle mengumumkan dukungan untuk Wayang.

Ansible juga mencoba, tetapi kedua tim tidak menyukainya sebagai suatu sistem. Ada juga masalah keamanan: Kemungkinan pada tahun 2013 sangat berbeda dari yang sekarang.

Kami meluncurkan dua proyek berbeda dengan fungsi yang sama secara paralel. Dan semuanya bekerja dengan baik, ada perasaan bahwa ada sesuatu yang salah di sini dan harus dibiarkan begitu saja. Bagaimana kami memilih?

Artem: Programmer menulis di Chef, admin menulis di Wayang. Idenya adalah apa yang akan kami coba, lalu bandingkan mana yang lebih baik dan pilih. Tetapi ketika kami berkumpul, ketika waktu akhirnya berlalu, dualitas mulai menciptakan masalah, karena volume kode bertambah, terus bertambah dan semua orang menyukai segalanya, pengembang menulis dan mengotomatisasi.

Saya mengumpulkan semua orang dan bertanya apa yang akan kami tulis. Programmer berkata: "Kami benar-benar menyukai Chef." Dan admin: "Dan kepada kami di Wayang!". Itu benar-benar timah. Saya membandingkan dan memahami bahwa dalam lingkungan saat ini dan parameter saat ini tidak ada cara obyektif untuk memilih produk ini atau itu.

Sebagai hasilnya, saya membuat, seperti yang mereka katakan di negara kami, pemilihan dengan hasil yang dapat diprediksi. Beberapa jenis suara "tertutup" di antara para peserta. Tetapi tidak ada pemalsuan, ada efek kondisional pada otak, akibatnya dipilihlah Wayang. Saya memutuskan bahwa saya akan menenangkan pengembang yang tersinggung lebih cepat daripada admin yang tersinggung. Tidak ada kriteria seleksi lain.

Sergey: Pada saat itu, kami sudah lama berpikir bagaimana menempatkan binarisme. Pada slide Anda dapat melihat foto dari papan dan pertemuan kami. Kami memutuskan bahwa Anda perlu menggunakan semacam sistem pengemasan, dan bukan sepeda Anda. Sekali lagi memenangkan pikiran.

Bahkan, kami memilih bukan RPM, tetapi IPS - manajer paket Solaris. Kami mengimpor sendiri dari versi ke-11 ke dalam sepuluh besar, yang berdiri, dan mulai menggunakannya. Menolak dari kruk dan zip bash yang ditulis sendiri pada saat itu adalah keputusan yang paling tepat.

Artem: Inilah mengapa itu masih penting: dalam resep, hasilnya muncul dalam bentuk perubahan dalam nomor versi, itu membentang semakin jauh dari repositori dan menjadi perlu.

Ketika kami datang untuk melatih DevOps, Chef, semua hal ini, dan kami berpikir: "Sekarang mereka akan memberi tahu kami cara mentransfer binari", tetapi mereka tidak memberi tahu kami apa-apa tentang itu. Jawabannya biasanya: "Semua orang memutuskan dengan caranya sendiri dan keluar sebanyak yang dia bisa." Oleh karena itu, mereka menyadari bahwa respons industri terhadap hal ini adalah "42", seperti dari "Panduan Hitchhikers ke Galaksi", jawaban atas pertanyaan utama alam semesta.

Sergey: Kami juga memiliki perdebatan panjang tentang bagaimana membangun CI / CD, apa itu. Seperti Manajemen Konfigurasi - satu utilitas, mereka mengambil dan mengirim. Dan di sini ada banyak pilihan dan pilihan, mereka berargumen untuk waktu yang lama, para pengembang membuat sistem mereka sendiri, dan dalam operasi kami membuat milik kami sendiri untuk dihapus.

Pada saat itu, kami menyadari bahwa tidak ada solusi yang sempurna. Ambil saja semua yang telah kita peroleh dan bertahan. Para pengembang memiliki sistem perakitan sendiri, kami membuat pengiriman sendiri. Tidak ada pilihan yang sempurna, dan masih bekerja dengan tim yang berbeda dengan cara yang berbeda. Tidak ada yang ideal.

Kami juga memiliki tumpukan besar, sebagian besar kode kami tertanam dalam database: semua pemrosesan keuangan, di mana, sayangnya, paradigma itu adalah "semakin dekat dengan data, semakin cepat kerjanya". Oracle menjual, Fowler setuju. Transaksi finansial tergantung pada PS / SQL, kami tidak menemukan produk opensource yang akan membantu menyelesaikan masalah kami dengan versi dan pengiriman. Mungkin memang begitu, tetapi kami mulai menulis instrumen sendiri.

Artem: Sebenarnya, kami memiliki masalah besar, karena, sebagaimana disebutkan dalam slide awal, Produksi adalah server vertikal besar. Karenanya, menaikkan server vertikal besar yang sama ke Stage sangat mahal dan sangat sulit. Ini tidak terlalu buruk.

Faktanya adalah bahwa kita perlu meningkatkan suatu lingkungan yang kira-kira sama dalam kinerja dan mengisinya dengan data yang sama dalam volume dan, yang tidak kalah penting, kardinalitas, sehingga tes Tahap kami lulus dengan benar.

Inilah keputusan yang sangat sulit. Pertama-tama, apa yang kami lakukan dalam hal penskalaan - kami menyadari bahwa kami tidak dapat menyediakan kendaraan vertikal yang sama di Panggung seperti dalam pertempuran.Tetapi kita dapat, pada waktu X, memperbaiki indikator referensi permintaan kinerja sistem pada lingkungan Stage dan membandingkannya ketika paket baru diluncurkan. Jika mereka mulai berubah secara tidak normal, itu berarti ada sesuatu yang melayang di dalam kita dan ada yang tidak beres. Ini satu masalah.

Kemudian kami menemukan masalah dengan mentransfer data dari pertempuran ke Tahap untuk mengisinya dengan jumlah data yang sama. Tidak mungkin bahwa tidak ada orang yang tidak memiliki akses ke data pelanggan sesuai dengan dokumen yang memiliki akses ke sana.

Kami tidak memiliki hak untuk menuangkan data pribadi dan rahasia bank pelanggan ke dalam Stage. Untuk mentransfer data ini, saya menulis skrip kebingungan data sehingga tidak dapat dipulihkan dan tidak dapat dibandingkan dengan yang asli. Pada saat yang sama, penting bahwa tidak mungkin untuk mengganti semua nama dengan aaa bbb, karena kita kehilangan kardinalitas data, dan semua pemeriksaan kita di Panggung menunjukkan informasi yang salah.

Oleh karena itu, kami juga menulis skrip ini dengan tujuan untuk menghasilkan beberapa kardinalitas acak acak dari data teks ini sehingga permintaan kami akan menunjukkan gambar yang memadai yang sebanding dengan pertempuran, dan kami dapat memahami perubahannya.

Kami bergerak menjauh dari kondisi kinerja absolut, kami melihat perubahan. Situasi tidak memburuk dibandingkan dengan versi sebelumnya, yang, menurut pendapat kami, tidak buruk dalam kinerja.



Ini adalah iterasi kedua. Mungkin frasa kunci di sini adalah bahwa proyek berakhir di sini. Tidak ada proyek DevOps. Di sini awalnya pelanggan internal - saya. Saya mendapatkan hasil saya: instruksi berkurang, kesalahan selama rilis versi berkurang, konfigurasi pertempuran mulai berubah, dikelola melalui Wayang, menjadi terkontrol, dapat dimengerti. Apa yang saya inginkan adalah apa yang saya dapatkan.

Sergey: Ada sedikit perubahan dari kiriman Anda. Sekali lagi, tanggung jawab mengalir dari TI yang terpusat ke direktorat teknis.

Itu menjadi OPS lengkap dengan root. Ini sebenarnya membantu untuk memenuhi tugas dalam hal penghapusan modul baru. Kami mulai membuat modul lebih cepat, setelah tiga minggu eksekusi hanya dalam tiga hari tampak ideal bagi kami. Hasilnya nyata: ada dorongan, tim mulai menghasilkan ide tentang bagaimana dan bagaimana meningkatkan.



Apa yang kami lakukan dari sudut pandang unit terkait: kami memiliki tim yang terdiri dari 200 orang, 150 pengembang, 6 OPS. Ada banyak pengawalan, penjaga keamanan. Pertama - realisasi telah datang bahwa aplikasi ideal terbaik yang tidak perlu dibuat. Mereka mulai membahas hal ini, dan mencoba: jika seseorang memiliki kesempatan untuk melakukan sesuatu tanpa membuat aplikasi - semua orang baik-baik saja. Dan itu dilakukan dengan sangat cepat.

Artyom:Berikut ini contohnya, kami melakukan penawaran melalui git. Manajer sendiri datang dan mengajukan tawaran untuk pertempuran itu.

Sergey: Kami menemukan alat-alat seperti Gitlab, kami senang seseorang dapat bekerja dengan antarmuka grafis. Ada tombol "unduh", pengguna bahkan mungkin tidak mengerti apa yang sebenarnya dilakukan komit.

Pada saat yang sama, kami telah menulis skrip untuk memeriksa konten, misalnya, bahwa pdf adalah pdf, memeriksa ukuran file, dan logika lainnya sesuai dengan aturan yang dikeluarkan oleh tim keamanan. Orang mendapat kesempatan untuk memperbarui dokumen-dokumen ini tanpa membuat aplikasi. Beban pada ops telah menurun.

Kesulitan lain adalah bagaimana menghitung momen seperti itu. Dalam rutinitas, tidak jelas bagaimana mencari area masalah. Karena itu, kami muncul dengan skala kami sendiri dan menyebutnya "Serigala".

Kami terinspirasi oleh foto lama. Kami menganggap bahwa kami menetapkan jumlah serigala untuk setiap aplikasi yang dieksekusi, betapa membosankan dan membosankannya, dan kami tidak ingin melakukannya. Pada akhir bulan, mereka mempertimbangkan aplikasi mana yang paling banyak dimiliki serigala.

Mereka duduk sebagai satu kesatuan dan berpikir bagaimana cara menghilangkan aib ini. Cara membuatnya tidak perlu membuat aplikasi untuk ini, itu keren dan mengusir orang.

Tahap berikutnya, tempat kami menemukan metode otomasi, adalah bot. Kami menguasai Telegram API, mulai memotong bot untuk semua orang berturut-turut, terutama untuk diri kami sendiri. Kami menyimpulkan pemicu terakhir.



Bisnis menyukainya: ada situasi ketika ada sesuatu yang berbohong, semua orang mulai menelepon dan menanyakan apa yang terjadi. Dan agar seseorang dapat mengambil telepon, pilih perintah "insiden" dan baca insiden terbaru. Orang-orang mulai melakukan insiden secara lebih rinci sehingga tidak ada yang akan menelepon atau bertanya tentang mereka.

Kemudian kami mulai menulis fitur tambahan untuk mendapatkan informasi yang dulunya adalah pertanyaan di Jira. Bisnis ingin tahu apakah transfer telah selesai: memasukkan nomor, dapatkan hasilnya. Ini juga sangat memudahkan kehidupan dalam hal aplikasi.

Artyom:Pada saat yang sama, kami melakukan transformasi organisasi lain, tetapi sudah bersifat lokal, di dalam departemen Sergey. Kemudian kami sangat terinfeksi dengan gagasan seorang insinyur yang bertugas, dan terima kasih kepada Sergey, kami dapat membangun skema ini di departemen. Ada insinyur yang duduk pada insiden, ada insinyur yang duduk pada aplikasi, semua sisanya menghancurkan serigala, terlibat dalam penembakan mereka.

Bekerja dengan DEV

Sergey: Apa yang mulai dilakukan unit: penataan ulang muncul, orang-orang terlibat tidak hanya dengan serigala, tetapi juga dalam hal-hal lain. Pertama-tama, kami berdialog dengan pembangunan. Kami memberi tahu tim baru apa itu DevOps, cara memasaknya dengan benar, dan mengajarkan CM.

Kami melangkah jauh dari saat kami sendiri menulis resep, lalu mereka belajar mengeditnya, dan kemudian menulis sendiri. Kami juga berbicara tentang CI, membantu mengatur saluran pipa dan mengumpulkan paket. Kami membantu membangun lingkungan pengembangan yang aman.

Artem: Dari sudut pandang CI, ini semua sangat penting. Secara paralel, saya bertindak sebagai pelopor produk, memimpin proyek, dan memimpin tim pengembangan. Dan ini adalah kasus yang sangat menarik.

Pada tim kecil, kami menggabungkan fungsi operasi, yaitu Stage dan Prod di unit yang sama. Pada proyek-proyek kecil ini, produk-produk kecil, tim, dan infrastruktur, ini ternyata sangat nyaman. Anda melihat benar melalui bagaimana Anda akan menggulung pertempuran.

Sergey: Ketika seorang insinyur tempur membuat lingkungan pengujian, dia membuatnya satu lawan satu, mengetahui bahwa dia akan datang kepadanya nanti, dan dia akan menderita karenanya. Ini adalah faktor psikologis penting yang tidak bisa bebas, lebih baik melakukan semuanya sekaligus dan normal.



Apa yang terjadi? Di sini, banyak yang mengatakan bahwa tidak ada departemen DevOps, kami percaya bahwa kami memiliki departemen DevOps. Apa tugas utama departemen?

Dia berjalan, mempromosikan, berbicara tentang DevOps. Semua orang mengerti apa itu dan cara memasaknya. Mereka memberi tahu dan menunjukkan bagaimana produk baru dengan database dapat diluncurkan dalam lima menit.

Satu-satunya batasan kami adalah keamanan, koordinasi skema. Ketika kami memiliki mesin virtual dan skema disetujui, maka semuanya membutuhkan waktu lima menit. Semuanya berputar secara otomatis.

Artem: Ketika pada bulan Agustus saya meluncurkan produk baru dalam pertempuran, yaitu, produk yang benar-benar baru, kami meluncurkan 15-20 rilis per hari tanpa konflik dan ketegangan. Ada rasa nilai di sini: itu keren ketika Anda diam-diam tenang dan Anda pergi ke yang berikutnya.



Sergey:Saya akan berbicara tentang rasa sakit. Kami mendukung rencana pemulihan DRP dari awal. Dan ketika tidak ada otomatisasi, kami menyalin hampir konfigurasi di sana. Modul baru terus ditambahkan, dan rencana itu perlu terus diperbarui. Dengan kedatangan DevOps dan otomatisasi, paket menyusut: kami mengambil versi terbaru Git dan menambahkan rencana untuk itu.

Rencana penyebaran ini menjadi jujur. Ini didukung, antara lain, dengan menjalankan uji penyebaran. Kami melakukan uji coba, dan pada lari tempur kami berlari dengan beralih ke cadangan. Seluruh cerita rutin hilang. Omong-omong, ini membantu kami memindahkan tumpukan sedikit.

Kami dulu menggunakan SPARC Solaris, sekarang x86 muncul karena alasan sederhana: hari ini tidak ada yang menulis atau menguji aplikasi hipster untuk Sparc. Dan kami menggunakan misalnya Haproxy, bersama dengan pengembang kami melihat perbaikan bug untuk Solaris. Itu mengganggu kami, saya tidak ingin menanggungnya lagi. Kami telah memilih platform di mana semua orang menguji produk, dan sekarang kami bekerja secara normal. Ini juga menggerakkan kami untuk mempercepat seluruh proses.

Artem: Ini umumnya membuka gerbang ke dunia baru yang penuh keajaiban. Karena munculnya x86 memungkinkan kami untuk menggunakan utilitas yang sangat relevan dan berguna untuk tugas kami. Terlebih lagi, ketika kami mendapat kesempatan ini, kami secara bersamaan bergerak menuju pengelompokan.

Faktanya, sekarang semuanya, kecuali untuk pemrosesan pusat dan nuklir, terkelompok dan berfungsi dengan baik bersama kami. Kami tidak khawatir: apakah tidak ada downtime atau dibutuhkan maksimum satu menit, bahkan ketika tidak ada cluster.

Satu-satunya tempat ia tinggal dan setidaknya berusia dua jam adalah migrasi skema pemrosesan terpusat. Sekarang butuh delapan menit.



Sergey: Pada slide adalah dokumen baru, aplikasi satu baris: merge in git. Tidak ada lagi sepuluh lembar A4.

Menyebarkan modul baru membutuhkan waktu hingga tiga jam. Ini adalah beberapa kasus sulit ketika Anda perlu melakukan sesuatu di Oracle, misalnya, dapatkan mesin virtual. Offset hilang. Saya tidak ingat ada yang salah. Tentu saja, ada beberapa kekasaran, tetapi mereka semua kecil, sembrono, sangat cepat diperbaiki.



Apa yang memungkinkan kami mencapai kesuksesan? Pertama-tama, kami tidak memulai revolusi di sini dan sekarang. Saya tidak mengatakan: "Kita perlu mengimplementasikan DevOps dalam tiga minggu." Kami mendekati proses ini secara metodis, gelisah untuk waktu yang lama, memberi tahu orang-orang, meneteskan otak, membicarakan tujuan yang kami capai.

Artem: Saya melawan pertanyaan dari pihak berwenang: "Artem, kapan DevOps?" Dia mengatakan bahwa tidak akan ada batas waktu, kami coba di Prod, jangan tanya apa-apa.

Sergey:Di sisi lain, semuanya juga sangat keren. Kami tidak memaksakan pada semua unit teknologi yang kami gunakan. Perusahaannya besar, tetangga-tetangganya terlihat, mereka berkata: "Ya, bagus, bagus, tapi kami akan menyebarkan setiap enam bulan." Mereka tidak membutuhkannya. Kami tidak berjalan, tidak memberi tahu, bahwa kami memiliki satu-satunya keputusan yang tepat. Di suatu tempat kami tidak ingin menggunakan tumpukan kami, untuk itu kami telah mengumpulkan skrip bash sederhana yang memungkinkan integrasi dengan perintah lain.

Artem: Di sini saya yakin bahwa bagian atas tidak dapat dipaksa untuk mengimplementasikan DevOps. Ini tidak realistis untuk proyek semacam itu.



Sergey: Kami menganalisis di mana kami kehilangan sebagian besar waktu kami: hari ini kami kehilangan sebagian besar waktu kami untuk keamanan.

Kami tahu cara bekerja dengan cepat, menyebarkan dengan cepat, tetapi menyetujui skema penempatan - ini semacam neraka. Sekarang kami melihatnya, itu mengingatkan hal yang sama ketika ada divisi yang sama sekali berbeda dari Dev dan Ops. Sekarang kami tidak memiliki rencana, kami berpikir tentang bagaimana memasukkan keamanan dalam proses kami sehingga mereka dapat menganalisis perubahan.

Artem: Misalnya, Anda dapat menggunakan Gabung untuk ini, lihat apa yang telah berubah dalam resep. Penjaga keamanan juga seorang insinyur.

Sergey:Seringkali proses formal kita tidak memberikan keamanan nyata. Ketika kami melakukan audit, kami memahami bahwa semua prosedur telah berlalu, tetapi kami belum menerima tingkat keamanan yang diinginkan, dan banyak waktu dan sumber daya telah dihabiskan. Kami terus-menerus menemukan beberapa masalah yang terjadi karena buruknya integrasi proses keamanan dan CI / CD.

Dari sudut pandang OPS, kami masih memiliki masalah membuang-buang waktu pada CI dan menyesuaikan resep. Benda ini sudah mulai mendapatkan "serigala." Oleh karena itu, kami melihat sistem untuk menyajikan kerangka kerja bagi pengembang, kami melihat ke arah Docker, Kubernetes, sehingga kami dapat menulis: "Guys, ada alat, tidak ada dokumen besar, Anda dapat menyatukan proses pengiriman."

Kami ingin memajukan ide ini, tetapi keamanan kembali menolak. Mereka berkata: "Apa jenis jaringan virtual yang Anda miliki, bagaimana layanan ini akan berjalan tanpa firewall?" Ada beberapa kontradiksi, tetapi, saya pikir, kita akan tetap menang.

Artem: Saya memiliki rasa sakit sendiri, saya ingin menyelesaikannya. Kami memiliki masalah yang sangat besar: kami adalah perusahaan, dan kami bukan satu-satunya perusahaan seperti itu, ada perwakilan yang berada dalam situasi yang sama. Kami berada di bawah kendali konstan dari regulator, Bank Sentral terus-menerus datang dengan audit. Kami melalui audit, melalui audit yang tampaknya independen.

Sulit untuk menyalahkan auditor, ia melakukan pekerjaan berdasarkan standar yang menyatakan bahwa perangkat keras fisik harus merupakan mesin non-virtual yang terpisah. Tidak ada wadah

Tidak ada satu pun standar internasional yang saat ini telah memindahkan sedikit pun ke arah teknologi baru. Ada lubang hitam. Mereka tidak menyadari bahwa ini adalah masalah besar. Saya tidak bisa menyalahkan auditor, mereka melakukan audit sesuai standar. Mereka tidak memiliki tempat untuk mengambil ini, tetapi tidak ada standar yang mencoba dalam hal ini untuk berubah, untuk mengubah suatu tempat dan bergerak.

Saya perlu mencari cara bagaimana membuat gambaran tentang keberadaan perusahaan dengan kata-kata mengerikan ini sehingga semuanya benar dan jujur.

Jika Anda bosan membaca lama - kami sarankan mendengarkan rilis podcast "Lima Menit PHP" dengan teman-teman kami Baruch Sadogursky dan Vyacheslav Kuznetsov. Tren DevOps, DecSecOps, kemenangan Kubernetes, dan laporan State of DevOps 2018 oleh DORA.

Dan jika Anda ingin laporan yang lebih keren, datanglah ke konferensi DevOops 2018. Akan ada Baruch, dan Glory, dan bahkan John Willis ! Semua pembicara dan program ada di situs .

Bonus bagus: hingga 1 Oktober, tiket untuk DevOops 2018 dapat dipesan dengan diskon .