Direktur operasi portal Banki.ru, Andrei Nikolsky mengatakan pada konferensi tahun lalu
DevOpsDays Moscow tentang layanan anak yatim: bagaimana mengidentifikasi anak yatim dalam infrastruktur, apa layanan anak yatim yang buruk, apa yang harus dilakukan dengan mereka, dan bagaimana menjadi jika tidak ada yang membantu.
Di bawah potongan adalah versi teks laporan.
Halo rekan! Nama saya Andrey, saya memimpin operasi di Banki.ru.
Kami memiliki layanan hebat, ini adalah layanan monolitik, ada layanan dalam arti yang lebih klasik, ada yang sangat kecil. Dalam terminologi pekerja dan tani saya, saya katakan bahwa jika layanannya sederhana dan kecil, maka itu mikro, dan jika tidak sangat sederhana dan tidak kecil, maka itu hanyalah sebuah layanan.
Layanan Pro
Saya akan membahas kelebihan layanan dengan cepat.
Yang pertama adalah penskalaan. Anda dapat dengan cepat melakukan sesuatu pada layanan dan memulai produksi. Anda telah tiba lalu lintas, Anda telah mengkloning layanan. Anda masih mendapat lalu lintas, Anda masih dikloning dan hidup dengannya. Ini adalah bonus yang baik, dan, pada prinsipnya, ketika kami mulai, itu dianggap yang paling penting di antara kami, mengapa kami melakukan semua ini.
Kedua, pengembangan terisolasi, ketika Anda memiliki beberapa tim pengembangan, beberapa pengembang berbeda di setiap tim, dan setiap tim melihat beberapa jenis layanan.
Ada nuansa dengan tim. Pengembang berbeda. Dan ada, misalnya,
butiran salju . Saya pertama kali melihat ini dengan Maxim Dorofeev. Kadang-kadang orang memiliki kepingan salju di beberapa tim, dan beberapa tidak. Ini membuat berbagai layanan yang digunakan di perusahaan sedikit tidak merata.
Lihat gambar: dia adalah pengembang yang baik, dia memiliki tangan yang besar, dia bisa melakukan banyak hal. Masalah utama adalah dari mana tangan ini tumbuh.
Layanan memungkinkan untuk menggunakan bahasa pemrograman yang berbeda yang lebih cocok untuk tugas yang berbeda. Beberapa layanan di Go, beberapa di Erlang, beberapa di Ruby, beberapa di PHP, beberapa di Python. Secara umum, Anda dapat berbalik sangat luas. Ada juga nuansa di sini.
Arsitektur berorientasi layanan terutama tentang devops. Artinya, jika Anda tidak memiliki otomatisasi, tidak ada proses penyebaran, jika Anda mengonfigurasi dengan tangan Anda, konfigurasi Anda dapat berubah dari instance layanan ke instance, dan Anda harus pergi ke sana untuk melakukan sesuatu, maka Anda berada di neraka.
Misalnya, Anda memiliki 20 layanan, dan Anda perlu menggunakan dengan tangan Anda, Anda memiliki 20 konsol, dan Anda secara bersamaan menekan "masuk", seperti seorang ninja. Ini tidak terlalu bagus.
Jika Anda memiliki layanan setelah pengujian (jika ada pengujian, tentu saja), dan Anda juga harus menyelesaikannya dengan file sehingga berfungsi dalam produksi, saya juga punya kabar buruk untuk Anda.
Jika Anda mengandalkan layanan khusus Amazon dan bekerja di Rusia, maka dua bulan lalu Anda juga memiliki "Semuanya terbakar, saya baik-baik saja, semuanya keren."
Kami menggunakan Ansible untuk penyebaran otomatisasi, Wayang untuk konvergensi, Bambu untuk otomatisasi penyebaran, Confluence untuk menggambarkan semuanya entah bagaimana.
Saya tidak akan membahas hal ini secara rinci, karena laporannya lebih tentang praktik interaksi, dan bukan tentang implementasi teknis.
Sebagai contoh, kami memiliki masalah bahwa Puppet di server bekerja dengan Ruby 2, dan beberapa aplikasi ditulis di bawah Ruby 1.8, dan bersama-sama keduanya tidak berfungsi. Ada semacam kusen yang terjadi. Dan ketika Anda perlu menyimpan beberapa versi Ruby di mesin yang sama, Anda biasanya memiliki masalah.
Sebagai contoh, kami memberikan setiap pengembang platform di mana ada hampir semua yang kami miliki, semua layanan yang dapat dikembangkan sehingga ia memiliki lingkungan yang terisolasi, ia dapat memecahnya dan membangunnya sesuai keinginan.
Itu terjadi bahwa Anda memerlukan beberapa jenis paket yang dikompilasi khusus dengan dukungan untuk sesuatu di sana. Ini cukup sulit. Saya telah mendengarkan laporan di mana gambar buruh pelabuhan berbobot 45 GB. Di Linux, tentu saja, lebih sederhana, semuanya lebih kecil di sana, tetapi bagaimanapun, tidak akan ada cukup tempat.
Nah, ada dependensi yang saling bertentangan ketika Anda memiliki satu bagian dari proyek tergantung pada pustaka dari satu versi, bagian lain dari proyek pada versi yang berbeda, dan pustaka tidak disatukan sama sekali.
Kami memiliki situs dan layanan di PHP 5.6, kami malu akan hal itu, tetapi apa yang harus dilakukan. Ini adalah satu situs kami. Ada situs dan layanan di PHP 7, ada lebih banyak dari mereka, kami tidak malu pada mereka. Dan setiap pengembang memiliki basis sendiri, di mana ia dengan senang hati melihatnya.
Jika Anda menulis di perusahaan dalam satu bahasa, maka tiga mesin virtual per pengembang - kedengarannya normal. Jika Anda memiliki bahasa pemrograman yang berbeda, maka situasinya menjadi lebih buruk.
Anda memiliki situs dan layanan tentang ini, ini, kemudian platform lain untuk Go, satu platform untuk Ruby, Redis lain di samping. Akibatnya, semua ini berubah menjadi bidang besar untuk dukungan, dan sementara itu, beberapa di antaranya mungkin pecah.
Oleh karena itu, kami mengganti roti bahasa pemrograman dengan menggunakan kerangka kerja yang berbeda, karena kerangka kerja dalam PHP sangat berbeda, mereka memiliki kemampuan yang berbeda, komunitas yang berbeda, dukungan yang berbeda. Dan Anda dapat menulis layanan sehingga Anda sudah memiliki sesuatu yang siap untuk itu.
Setiap layanan memiliki timnya sendiri.
Nilai tambah utama kami, yang mengkristal selama beberapa tahun, adalah bahwa setiap layanan memiliki timnya sendiri. Ini nyaman untuk proyek besar, Anda dapat menghemat waktu pada dokumentasi, manajer sangat menyadari proyek mereka.
Tugas dari dukungan dapat dilempar dengan sempurna. Misalnya, layanan asuransi mogok. Dan segera tim asuransi pergi untuk memperbaiki.
Fitur baru dibuat dengan cepat, karena ketika Anda memiliki satu layanan atom, Anda dapat dengan cepat memasukkan sesuatu ke dalamnya.
Dan ketika Anda melanggar layanan Anda, dan ini pasti terjadi, Anda tidak melukai layanan orang lain, dan pengembang dengan bit dari tim lain tidak menggunakan Anda dan mereka tidak mengatakan: "Aduh, jangan lakukan itu."
Seperti biasa, ada nuansa. Kami memiliki tim yang stabil, manajer dipaku ke tim. Ada dokumen yang jelas, manajer memonitor ini semua. Setiap tim dengan manajer memiliki beberapa layanan, dan ada titik kompetensi tertentu.
Jika tim mengambang (ini kadang-kadang juga digunakan bersama kami), ada metode yang bagus yang disebut peta bintang.
Anda memiliki daftar layanan dan orang. Tanda bintang berarti bahwa seseorang adalah ahli dalam layanan ini, sebuah buku berarti bahwa seseorang sedang mempelajari layanan ini. Tugas manusia adalah mengubah sebuah buku kecil untuk tanda bintang. Dan jika tidak ada yang tertulis di seberang layanan, maka masalah mulai, tentang yang saya akan terus berbicara.
Bagaimana layanan yatim muncul?
Masalah pertama, cara pertama, untuk mendapatkan layanan anak yatim di infrastruktur Anda adalah merumahkan orang. Adakah yang pernah terjadi ketika tenggat waktu tiba dari bisnis sebelum mereka mengevaluasi tugas? Terkadang tenggat waktu sangat ketat dan tidak cukup waktu untuk dokumentasi. "Kita harus menyerahkan layanan ke produksi, maka kita akan menambahkannya."
Jika tim kecil, kebetulan ada satu pengembang di dalamnya yang menulis semuanya, sisanya ada di sayap. "Saya menulis arsitektur dasar, Anda memberi saya antarmuka." Kemudian di beberapa titik manajer, misalnya, pergi. Dan selama periode ini, ketika manajer telah pergi, dan yang baru belum ditunjuk, pengembang sendiri memutuskan ke mana layanan bergerak, apa yang terjadi di sana. Dan seperti yang kita ketahui (mari kita kembali beberapa slide), di beberapa tim ada orang-kepingan salju, kadang-kadang kepingan salju timlid. Lalu dia berhenti, dan kami mendapat layanan anak yatim.
Pada saat yang sama, tugas-tugas dari dukungan dan dari bisnis tidak hilang, mereka menetap di jaminan. Jika ada kesalahan arsitektur selama pengembangan layanan, mereka juga mengendap dalam jaminan. Layanan perlahan-lahan merendahkan.
Bagaimana cara mengidentifikasi anak yatim?
Daftar ini menggambarkan situasi dengan baik. Siapa yang belajar sesuatu di infrastruktur?
Tentang cara kerja yang terdokumentasi: ada layanan dan, secara umum, ini berfungsi, ia memiliki manual dua halaman, cara bekerja dengannya, tetapi tidak ada yang tahu cara kerjanya di dalam.
Atau, misalnya, ada semacam pemendek tautan. Misalnya, kami sekarang menggunakan tiga penyingkat tautan untuk tujuan berbeda di berbagai layanan. Inilah konsekuensinya.
Sekarang saya akan menjadi kapten bukti. Apa yang perlu dilakukan? Pertama, Anda perlu mentransfer layanan ke manajer lain, tim lain. Jika pemimpin tim Anda belum berhenti, maka di tim lain ini, ketika Anda memahami bahwa layanan ini seperti anak yatim, Anda harus menyertakan seseorang yang setidaknya memahami sesuatu tentang dia.
Hal utama: Anda harus memiliki prosedur transmisi tertulis darah. Dalam kasus kami, saya biasanya mengikuti ini, karena saya perlu ini berfungsi. Manajer membutuhkan ini untuk disampaikan dengan cepat, dan apa yang akan terjadi padanya nanti tidak begitu penting bagi mereka.
Cara berikutnya untuk membuat anak yatim adalah "Ayo kita lakukan outsourcing, itu akan lebih cepat, dan kemudian kita akan mentransfernya ke tim." Jelas bahwa setiap orang memiliki beberapa rencana dalam tim, antrian. Seringkali pelanggan bisnis berpikir bahwa agen outsourcing akan melakukan hal yang sama dengan departemen teknis yang ada di perusahaan. Walaupun motivator mereka berbeda. Outsourcing memiliki solusi teknologi yang aneh dan solusi algoritmik yang aneh.
Misalnya, kami memiliki layanan di mana Sphinx berada di berbagai tempat yang tidak terduga. Saya akan memberi tahu Anda nanti apa yang harus saya lakukan.
Agen outsourcing memiliki kerangka kerja yang ditulis sendiri. Ini hanya PHP biasa dengan copy-paste dari proyek sebelumnya, di mana Anda dapat menemukan semuanya. Kruk besar dalam skrip deploy, ketika Anda perlu mengubah beberapa baris dalam beberapa file dengan beberapa skrip Bash yang kompleks, sementara skrip deploy ini dipanggil oleh skrip ketiga. Akibatnya, Anda mengubah sistem penempatan, memilih sesuatu yang lain, naik, dan layanan Anda tidak berfungsi. Karena ada 8 lebih banyak tautan untuk diletakkan di antara folder yang berbeda. Atau kebetulan bahwa seribu catatan berhasil, tetapi seratus ribu hilang.
Saya akan terus menjadi kapten. Menerima layanan dari outsourcing adalah prosedur yang diperlukan. Siapa yang terjadi bahwa layanan dari agen outsourcing tiba, tetapi tidak diterima di mana pun? Tentu saja, ini tidak sepopuler layanan anak yatim, tetapi tetap saja.
Layanan harus diperiksa, layanan harus ditinjau, kata sandi harus diubah. Kami memiliki kasus ketika layanan melemparkan kami, di sana panel admin “jika login == 'admin' && password == 'admin' ...” ditulis langsung dalam kode. Kami duduk dan berpikir, dan orang-orang menulis ini pada 2018?
Menguji volume penyimpanan juga merupakan keharusan. Anda perlu melihat apa yang akan terjadi pada seratus ribu catatan, bahkan sebelum Anda memulai layanan ini di suatu tempat dalam produksi.
Kirim layanan untuk revisi tidak boleh malu. Ketika Anda mengatakan: "Kami tidak akan menerima layanan ini, kami memiliki 20 tugas, lakukan, maka kami akan menerima", ini normal. Hati nurani tidak boleh sakit dari kenyataan bahwa Anda mengganti seorang manajer atau bahwa bisnis menghabiskan uang. Bisnis kemudian akan menghabiskan lebih banyak.
Kami memiliki kasus ketika kami memutuskan untuk membuat proyek percontohan pada outsourcing.
Itu disampaikan tepat waktu, dan ini adalah satu-satunya kriteria kualitas. Oleh karena itu, mereka membuat proyek percontohan lain, bahkan bukan proyek percontohan sama sekali. Layanan ini diterima, kata mereka dengan cara administrasi, ini kode Anda, ini tim, ini manajer Anda. Layanan benar-benar sudah mulai menghasilkan keuntungan. Terlebih lagi, pada kenyataannya, mereka tetap yatim piatu, tidak ada yang mengerti bagaimana mereka bekerja, dan manajer dengan segala cara yang memungkinkan menolak tugas mereka.
Ada konsep bagus lainnya - pengembangan partisan. Ketika suatu departemen, sebagai suatu peraturan, adalah departemen pemasaran, mereka ingin menguji suatu hipotesis, dan memesan seluruh layanan outsourcing. Lalu lintas mulai mengalir padanya, mereka menutup dokumen, menandatangani tindakan dengan kontraktor, mulai beroperasi dan berkata: "Dudes, kami memiliki layanan di sini, sudah memiliki lalu lintas, itu membawa kita uang, mari kita ambil itu". Kami adalah: "Oppa, bagaimana bisa begitu."
Dan satu cara lagi untuk mendapatkan layanan anak yatim: ketika beberapa tim tiba-tiba dimuat, manajemen mengatakan: "Mari kita transfer layanan dari tim ini ke tim lain, itu memiliki beban lebih sedikit." Dan kemudian kami akan pindah ke tim ketiga, dan kami akan mengubah manajer. Dan pada akhirnya, kami kembali memiliki anak yatim.
Apa masalah dengan anak yatim?
Siapa yang tidak tahu, ini adalah kapal dari garis Wasa dibesarkan di Swedia, terkenal karena tenggelam 5 menit setelah diluncurkan. Dan raja Swedia, omong-omong, tidak mengeksekusi siapa pun untuk ini. Itu dibangun oleh dua generasi insinyur yang tidak bisa membangun kapal seperti itu. Efek alami.
Omong-omong, kapal itu bisa tenggelam jauh lebih buruk, misalnya, ketika raja mengendarainya di suatu tempat dalam badai. Jadi, dia langsung tenggelam, menurut ajail ada baiknya gagal lebih awal.
Jika kita gagal lebih awal, biasanya tidak ada masalah. Misalnya, selama penerimaan mereka mengirim revisi. Dan jika kita telah gagal dalam produksi, ketika uang diinvestasikan, maka mungkin ada masalah. Konsekuensinya, sebagaimana mereka disebut dalam bisnis.
Mengapa layanan yatim berbahaya:
- Layanan mungkin putus tiba-tiba.
- Layanan diperbaiki untuk waktu yang lama atau tidak diperbaiki sama sekali.
- Masalah keamanan.
- Masalah dengan peningkatan dan pembaruan.
- Jika layanan penting rusak, reputasi perusahaan akan terganggu.
Apa yang harus dilakukan dengan layanan anak yatim?
Sekali lagi, apa yang harus dilakukan. Pertama, harus ada dokumentasi. Selama 7 tahun di Banki.ru saya diajari bahwa penguji tidak boleh mengambil kata untuk pengembang, dan operasi tidak boleh mengambil kata untuk semua orang. Perlu untuk memeriksa.
Kedua, perlu untuk menulis skema interaksi, karena kebetulan layanan yang tidak diterima mengandung dependensi yang tidak dibicarakan orang. Misalnya, pengembang meletakkan layanan pada kunci mereka ke Yandex.Maps atau Dadata. Anda telah kehabisan batas bebas, semuanya telah rusak, dan Anda tidak tahu apa yang terjadi sama sekali. Semua garu seperti itu harus dijelaskan: layanan menggunakan Dadata, Sms, sesuatu yang lain.
Ketiga, bekerja dengan utang teknis. Ketika Anda membuat beberapa tongkat atau menerima layanan dan mengatakan bahwa sesuatu harus dilakukan, Anda perlu memastikan bahwa mereka melakukannya. Karena dengan begitu mungkin ternyata lubang kecil itu tidak begitu kecil, dan Anda jatuh di sana.
Dengan tugas-tugas arsitektur, kami punya cerita tentang Sphinx. Di salah satu layanan, Sphinx digunakan untuk memasukkan daftar. Hanya daftar pagination, tapi itu diindeks ulang setiap malam. Itu disusun dari dua indeks: satu diindeks setiap malam besar, dan masih ada indeks kecil yang mengacaukannya. Setiap hari, dengan probabilitas 50%, itu akan meledak atau tidak, selama perhitungan, indeks berdenyut, dan berita berhenti diperbarui di halaman utama. Awalnya 5 menit, sementara indeks diindeks ulang, kemudian indeks tumbuh, dan pada beberapa titik indeks mulai kembali 40 menit. Ketika kami hentikan itu, kami menghela napas lega, karena jelas bahwa sedikit waktu lagi akan berlalu, dan indeks kami akan diindeks ulang penuh waktu. Ini akan menjadi file untuk portal kami, delapan jam tidak ada berita - itu saja, bisnis telah berdiri.
Rencana kerja dengan layanan anak yatim
Sebenarnya, ini sangat sulit dilakukan, karena devops adalah tentang komunikasi. Saya ingin berada dalam hubungan yang baik dengan kolega saya, dan ketika Anda mengalahkan kolega dan manajer dengan peraturan di kepala, mereka mungkin memiliki perasaan yang bertentangan dengan orang-orang yang melakukan ini.
Selain semua poin ini, ada hal penting lainnya: untuk setiap layanan spesifik, untuk setiap bagian spesifik dari prosedur penyebaran, orang-orang tertentu harus bertanggung jawab. Ketika tidak ada orang dan Anda harus menarik beberapa orang lain, untuk mempelajari semuanya, itu menjadi sulit.
Jika semua ini tidak membantu, dan layanan anak yatim masih yatim piatu, tidak ada yang mau membawanya sendiri, dokumentasi tidak ditulis, tim yang dipanggil ke layanan ini menolak untuk melakukan sesuatu, ada cara mudah untuk mengulang semuanya .
Artinya, Anda mengambil persyaratan layanan lagi dan menulis layanan baru, lebih baik, pada platform yang lebih baik, tanpa solusi teknologi yang aneh. Dan bermigrasi ke sana dalam pertempuran.
Kami memiliki situasi ketika kami menggunakan layanan pada Yii 1 dan menyadari bahwa kami tidak dapat mengembangkannya lebih lanjut, karena kami telah kehabisan pengembang yang dapat menulis dengan baik dalam Yii 1. Semua pengembang menulis dengan baik di Symfony ketiga. Apa yang harus dilakukan Kami mengambil waktu, mengalokasikan tim, mengalokasikan manajer, menulis ulang proyek dan dengan lancar mengalihkan lalu lintas ke sana.
Setelah itu, layanan lama dapat dihapus. Ini adalah prosedur favorit saya, ketika Anda perlu mengambil dan membersihkan beberapa layanan dari sistem manajemen konfigurasi dan kemudian pergi untuk melihat bahwa semua mobil pada produksi telah dilunasi sehingga pengembang tidak memiliki jejak yang tersisa. Repositori di git tetap ada.
Ini semua yang ingin saya bicarakan, saya siap membahas, topiknya holistik, banyak yang melayang di dalamnya.
Pada slide itu tentang fakta bahwa Anda menyatukan bahasa. Contohnya adalah ukuran gambar. Tetapi apakah benar-benar perlu untuk dengan kuat ke satu bahasa? Karena mengubah ukuran gambar dalam PHP, Anda bisa melakukannya di Golang.Sebenarnya, ini tidak perlu, seperti semua praktik lainnya. Mungkin, dalam beberapa kasus, bahkan tidak diinginkan. Tetapi Anda perlu memahami bahwa jika Anda memiliki 50 orang di departemen teknis, 45 di antaranya adalah pengembang PHP, 3 lainnya adalah devops yang dapat melakukan Python, Ansible, Puppet dan semacamnya, dan hanya satu dari mereka yang menulis tentang beberapa Pergi layanan untuk mengubah ukuran gambar, maka ketika dia pergi, pemeriksaan pergi bersamanya. Dan pada saat yang sama, Anda perlu mencari pengembang khusus pasar yang mengetahui bahasa ini, terutama jika itu jarang. Artinya, dari sudut pandang organisasi, ini bermasalah. Dari sudut pandang para devops, Anda tidak hanya perlu mengkloning beberapa buku pedoman yang sudah jadi yang Anda gunakan untuk menggunakan layanan, tetapi Anda harus menulisnya lagi.
Kami sekarang melihat layanan di Node.js, dan itu hanya akan menjadi platform terdekat untuk setiap pengembang dengan bahasa yang terpisah. Tapi kami duduk berpikir bahwa permainan itu sepadan dengan lilin. Maksudnya, pertanyaan di sini adalah duduk dan berpikir.
Bagaimana Anda memonitor layanan Anda? Bagaimana Anda mengumpulkan dan melacak log?Kami mengumpulkan log di Elasticsearch dan dimasukkan ke Kibana, dan tergantung pada lingkungan produksi atau pengujian, kolektor yang berbeda digunakan di sana. Di suatu tempat Lumberjack, di tempat lain sesuatu, saya tidak ingat lagi. Dan masih ada beberapa tempat di layanan tertentu di mana kami menempatkan Telegraf dan peluru di tempat lain secara terpisah.Bagaimana cara hidup dengan Wayang dan Mungkin dalam satu lingkungan?Faktanya, kita sekarang memiliki dua lingkungan, satu adalah Wayang, yang lain Ansible. Kami sedang berupaya untuk membuat hibridisasi mereka. Kemungkinan adalah lingkungan yang baik untuk pengaturan awal, Wayang adalah hal yang buruk untuk pengaturan awal karena memerlukan tangan untuk bekerja secara langsung dengan pad, dan Wayang memberikan konvergensi konfigurasi. Ini berarti bahwa situs itu sendiri tetap up-to-date, dan agar mesin ansiblized tetap up-to-date, Anda perlu mengejar buku pedoman dengan frekuensi berapa pun. Inilah perbedaannya.Bagaimana Anda menjaga kompatibilitas? Apakah Anda memiliki konfigurasi dalam Ansible dan Wayang?Ini adalah rasa sakit besar kami, kami menjaga kompatibilitas dengan tangan kami dan berpikir, seolah-olah sekarang, untuk pindah dari semua tempat ini. Ternyata Puppet menggulung paket dan mendukung beberapa tautan di sana, sementara Ansible, misalnya, menggulung kode dan mendorong konfigurasi aplikasi baru di sana.Presentasi itu tentang berbagai versi Ruby. Apa solusinya?Kita dihadapkan dengan ini di satu tempat, dan kita harus selalu mengingat hal ini. Kami hanya mematikan bagian yang berfungsi pada Ruby, yang tidak kompatibel dengan aplikasi, dan memisahkannya.Tahun ini, konferensi DevOpsDays Moscow akan diadakan pada 7 Desember di Technopolis. Hingga 11 November, kami menerima aplikasi untuk laporan. Email kami jika Anda ingin berbicara.
Pendaftaran untuk peserta terbuka, bergabunglah!