Oh, kode saya. Bagaimana menjadi administrator sistem

Wakil Direktur Teknis Mail.Ru Group Tatyana Bakharevskaya berbicara tentang jalur administrator sistem, keuntungan bekerja sebagai administrator sistem dan fitur operasi di perusahaan besar. Tatyana bertanggung jawab dan bertanggung jawab atas layanan dua portal terbesar Rusia.


Tuan rumah dari program ini adalah Pavel Shcherbinin.

- Ceritakan sedikit tentang dirimu.

- Saya memasuki profesi sejak lama. Dia mendapat pekerjaan sebagai administrator sistem junior di sebuah startup kecil yang sedang mengembangkan mesin pencari dan sejumlah proyek Internet lainnya. Itu Yandex, tempat saya bekerja selama bertahun-tahun. Dia tumbuh menjadi administrator sistem yang serius, kemudian memimpin departemen administrasi sistem. Pada tahun 2005, 5 orang bekerja di departemen ini, dan setelah 10 tahun - 250, itu adalah struktur besar, beberapa unit dibentuk. Kami belajar cara merekrut, membesarkan insinyur, membuat acara seperti Root, CIT. Di Yandex, saya bertanggung jawab atas operasi perusahaan yang terus-menerus tanpa gangguan, dan sekarang, sudah setahun, saya telah melakukan hal yang sama untuk Mail.Ru Group. Awalnya kelihatannya tugasnya sama, tetapi setelah diperiksa lebih dekat ternyata ada banyak kesamaan, tetapi ada cukup banyak perbedaan, dan ini menarik.

- Ada banyak istilah berbeda untuk operasi layanan. Ini hanya eksploitasi, dan administrator sistem, SRE, SE, DevOps. Ceritakan lebih lanjut tentang masing-masing. Atau apakah itu hal yang sama? Bagaimana mereka berbeda?

- Faktanya, administrator sistem adalah konsep yang cukup luas, dimulai dengan fakta bahwa seseorang dapat bertanggung jawab atas beberapa kantor kecil dengan infrastruktur kantor kecil untuk beberapa karyawan, berakhir dengan tanggung jawab untuk operasi berkelanjutan dari layanan yang sangat dimuat. Di beberapa titik, itu masih dibagi menjadi berbagai arah. Di perusahaan seperti Mail.Ru Group, Yandex, Google, administrator sistem lebih dekat dengan apa yang sekarang disebut kata buzz SRE - Site Reliability Engineer, yaitu orang yang bertanggung jawab atas ketersediaan situs.

Pekerjaan kami membutuhkan banyak pengetahuan berbeda tentang teknologi: Linux / Unix, jaringan, basis data, server web, teknologi cloud, komposisi peralatan yang kami gunakan untuk membangun layanan (prosesor, memori, disk) dan banyak lagi. Tentang teknologi, Anda perlu memahami cara menerapkannya, perbedaannya. Selalu ada banyak pekerjaan rutin yang perlu diotomatisasi. Anda juga perlu menulis kode. Administrator sistem modern / SRE sebagian besar adalah pemrogram. Saat ini, bahasa utama untuk otomatisasi adalah Python, plus, tentu saja, bash. Mengetahui C selalu menjadi nilai tambah. Sebagai contoh, dokumentasi Linux terbaik: buka kode kernel dan lihat bagaimana semuanya bekerja.

Penting juga untuk memahami bagaimana membangun sistem yang sarat muatan dan toleran terhadap kesalahan. Tentang ini, cukup banyak yang telah dikatakan di konferensi dan ditulis di Internet.

Secara total, untuk meringkas, insinyur modern yang bertanggung jawab atas layanan yang sangat dimuat harus dapat memprogram, mengetahui dan menerapkan berbagai teknologi, memiliki gagasan tentang bagaimana membangun layanan yang andal dan terukur.

- Mari kita kembali sedikit. Tahap awal sangat menarik. Mengapa Anda memilih operasi?

- Itu lucu. Pada tahun-tahun itu, semua gadis yang baik ingin menjadi akuntan. Saya juga ingin, jadi saya pergi ke kursus. Mereka mengatakan bahwa untuk menjadi seorang akuntan, Anda harus menguasai skor dan aritmometer Felix, saya memutuskan bahwa itu terlalu rumit, dan "mengetahui komputer" (seperti yang mereka tulis dalam iklan pekerjaan) akan membuat hidup dan pencarian pekerjaan saya lebih mudah. Akibatnya, ia pergi "untuk belajar komputer" di Institut Fisika Teknik Moskow terdekat, di Fakultas Sibernetika, di Departemen Komputer Elektronik. Ternyata di komputer ini, selain Word dan Excel, masih ada banyak hal - prosesor, memori, jaringan pipa, perangkat input-output. Di akhir studi, saya ingin menjadi seorang programmer. Pada kursus pertama, pemrograman agak sulit bagi saya, dan pada akhir studi saya, sangat mudah untuk menulis kode. Bisa melakukan ini selama berhari-hari. Di malam hari dia duduk dan menulis kode, dan malam berikutnya dia membuka matanya. Semuanya berjalan cukup baik, programnya berjalan. Tetapi saya menyadari bahwa saya adalah orang yang tajam, dan memutuskan untuk memilih sesuatu yang lebih sederhana. Dan mulai beroperasi, tetapi ternyata di sini juga tidak mudah, tetapi bahkan di tempat-tempat itu jauh lebih rumit. Tapi saya tetap tinggal, dan selama lebih dari 20 tahun saya telah melakukan ini.

- Saya ingin tahu pada titik apa Anda memutuskan untuk menjadi seorang programmer atau admin?

- Dengan berbagai cara. Selama beberapa tahun terakhir, saya telah menjumpai siswa baik di Yandex dan Mail.Ru. Orang-orang di perguruan tinggi datang untuk mencoba sendiri dalam pemrograman dan administrasi. Seseorang tetap beroperasi dan mengerti bahwa ini adalah miliknya. Seseorang, setelah bekerja sedikit, masuk ke dalam pengembangan. Seseorang yang telah bekerja dalam pengembangan memahami bahwa ia ingin memahami beberapa masalah lebih dalam, mencari tahu apa yang ada di bawah ini, di bawah programnya, bagaimana itu dioperasikan, bagaimana itu hidup, dan terbenam dalam operasi. Ada beberapa kasus batas yang sekarang disebut kata kunci DevOps. Orang-orang ini harus tahu banyak tentang perangkat keras, eksploitasi, dan kode.

Itu semua tergantung pada orangnya, pada apa yang dia suka dan tidak suka. Dan profesi ini sangat mirip, tumpang tindih dalam banyak hal.

- Legenda tentang Yandex bercerita tentang Anda bahwa pada suatu waktu Anda memiliki sakelar khusus yang dapat mematikan satu pusat data kapan saja untuk menguji stabilitas sistem. Ceritakan lebih banyak.

- Kisah ini dimulai bertahun-tahun yang lalu dengan insiden besar: hampir semua pusat data terputus di Yandex. Lebih tepatnya, satu terputus, tetapi mengandung semua peralatan jaringan perusahaan. Yandex tidak bekerja selama beberapa jam. Setelah itu, tugas ditetapkan untuk membuat semuanya dapat diandalkan, toleran terhadap kesalahan, sehingga semuanya akan bekerja jika terjadi terputusnya salah satu pusat data. Saat ini, masalah ini tidak begitu relevan, terutama untuk pusat data komersial. Keandalan menjadi jauh lebih tinggi, ada contoh bagaimana pusat data modern hidup selama beberapa hari dalam bahan bakar diesel. Tapi kemudian berbeda.

Selama beberapa tahun, kami menganalisis arsitektur semua aplikasi, menulis rencana tugas, bagaimana dan apa yang perlu dilakukan untuk memastikan toleransi kesalahan yang lengkap. Di mana tidak mungkin atau terlalu sulit, kami membahas SLA (perjanjian tingkat layanan). Perhatian utama difokuskan pada layanan yang populer dan penuh muatan. Pemadaman tes pertama sangat menakutkan. Setengah dari karyawan memantau data pemantauan. Mereka memutus dan menyalakan cukup cepat, menuliskan semua bug, menyelesaikan sejumlah sistem. Dan beberapa iterasi.

Setelah beberapa waktu, mereka sampai pada titik bahwa mereka dapat hidup dengan tenang selama satu atau dua jam, memutuskan satu pusat data. Semua orang mengerti bahwa keterampilan perlu dipertahankan, latihan teratur untuk memutuskan. Ini seperti dalam pipa: jika Anda tidak membuka faucet untuk waktu yang lama dan tidak menutupnya, itu menjadi asam dan Anda tidak akan membukanya pada saat yang tepat. Karena itu, kami secara teratur membuka dan menutup "keran". Dan itu berhasil. Saya menganggapnya sebagai pencapaian bahwa pada suatu malam mereka menelepon saya dan mengatakan bahwa pusat data telah jatuh, dan saya bertanya mengapa mereka membangunkan saya :-)

- Bagaimana menurut Anda, di mana garis antara pemrogram dan administrator sistem? Pada titik mana seorang programmer dapat mengatakan bahwa dia tidak bertanggung jawab untuk ini, tidak tahu database apa yang ada, ini untuk administrator. Atau wajah ini bukan?

- Tampaknya bagi saya bahwa admin bertanggung jawab untuk aplikasi "dari ujung hidung ke ujung ekor." Dengan cara yang baik, dia bisa masuk ke dalam kode, melihat cara kerjanya di sana, bagaimana memperbaikinya untuknya. Dia berpartisipasi dalam pilihan teknologi, karena ada teknologi yang bagus untuk programmer, sangat nyaman untuk menulis bersama mereka, tetapi tidak mungkin untuk hidup 24/7 bersama mereka.

Programmer dapat lebih fokus pada fitur-fitur produk yang mereka butuhkan: fungsionalitas tambahan, desain, kode tambahan yang memungkinkan proyek untuk skala yang lebih baik. Artinya, masih ada pemisahan. Dalam praktik internasional, ini adalah Keandalan Situs dan Insinyur Perangkat Lunak. Ada berbagai teori di mana dan bagaimana pemisahan peran harus terjadi. Tampak bagi saya bahwa paradigma yang diadopsi oleh Mail.Ru Group, di mana terdapat operasi dan pengembangan, dan ini adalah orang-orang yang berbeda, bekerja dengan sangat baik.

- Mungkin tidak semua orang tahu bagaimana mengaturnya di Mail.Ru Group. Ceritakan lebih banyak.

- Kami memiliki layanan operasi yang bertanggung jawab untuk pengoperasian layanan. Ini terdiri dari beberapa departemen. Setiap departemen bertanggung jawab atas produk atau kelompok produk tertentu, tergantung pada skala. Sebagai contoh, beberapa departemen terlibat dalam Mail: satu repositori, web lainnya. Dan ada departemen yang bekerja pada beberapa proyek, dalam skala yang lebih kecil.

Di rumah tangga kami - Mail, Cari, Portal, Klub pengiriman, "Yula", "My World", ICQ dan banyak lainnya. Ada proyek yang telah diluncurkan untuk waktu yang lama dan merupakan produk inti kami, misalnya, Mail dan Portal. Ada proyek yang telah kami beli yang kami tempatkan di infrastruktur kami, berbagi praktik operasional dengan mereka. Dan ada orang-orang yang dilahirkan bersama kami dan tumbuh sangat cepat, misalnya, "Yula". Perekonomiannya cukup beragam :-)

- Seperti apa arsitektur layanan Mail.Ru Group pada umumnya?

- Kami memiliki beberapa pusat data. Kami memiliki pusat data kami sendiri, baik milik kami maupun komersial, dalam peralatan dan jaringan komersial. Kapasitas total saluran di negara kami diukur dalam terabit.

Kami meng-host server proyek di beberapa pusat data sehingga menonaktifkannya tidak memengaruhi pengoperasian layanan. Sebagian besar proyek kami adalah situs web. Arsitekturnya standar: penyeimbang beban, di bawahnya server web, lalu server aplikasi, dan kemudian DBMS dan / atau penyimpanan.

Selanjutnya, detailnya dimulai.

Pada dasarnya, kita semua hidup di server besi, tetapi kami juga memiliki cloud. Misalnya, untuk pengembangan dan pengujian, cloud digunakan di OpenStack, tempat pengembangan dan pengujian dapat menerima sumber daya dengan mengklik tombol.

Kami menerapkan Kubernetes, tetapi proses ini membutuhkan banyak perubahan dalam proses operasi dan pengembangan. Itu tidak berjalan cepat. Kami mencoba melakukan semuanya dengan hati-hati agar tidak merusak apa pun.

Mari kita kembali ke apa yang terjadi dengan pengguna. Pertama, pengguna memasuki penyeimbang. Untuk menyeimbangkan beban, protokol jaringan BGP dan RIP digunakan, dan perangkat lunak tradisional - ipvs, haproxy, dan nginx. Setelah itu, server web menampilkan halaman yang indah kepada pengguna, terutama menggunakan nginx dan Apache.

Tetapi di belakang mereka ada server aplikasi. Karena, seperti yang saya katakan di atas, ada warisan dan proyek yang cukup baru, ada cukup banyak bahasa pemrograman di mana semua ini ditulis.

Sebagai DBMS untuk proyek-proyek baru, terutama MySQL, PostgreSQL dan Tarantool pengembangan internal kami digunakan. Pengguna seharusnya tidak merasakan hilangnya server penyimpanan atau bagiannya, kami mencoba untuk membuat cadangan dan mereplikasi data ke pusat data yang berdekatan.

Kami terutama menggunakan open source, karena kami memiliki banyak programmer dan insinyur di perusahaan kami yang dapat memperbaiki sesuatu kapan saja. Ada juga beberapa perkembangan. Sebagai contoh, repositori tempat surat-surat pengguna berada adalah pengembangannya sendiri.

- Berapa banyak orang yang Anda tundukkan?

- Sekarang sekitar 70, tetapi jumlah ini terus bertambah. Kami aktif berkembang, sekarang ada banyak posisi terbuka.

- Berapa banyak server yang mereka layani?

- Beberapa puluhan ribu server yang berlokasi di pusat data kami. Sebagian besar di Moskow, tetapi kami juga memiliki server di kota-kota lain, di AS dan Eropa. Semua armada server ini perlu dipantau dan dirawat, dirawat. Kita sendiri, tentu saja, tidak pergi ke pusat data, kecuali mungkin bertamasya.

- Berapa volume saluran?

"Beberapa terabit." Seluruh Grup Mail.Ru memiliki jaringan yang sama, yang melaluinya banyak informasi dikirimkan. Ambil setidaknya "VK" dan "OK", yang menunjukkan banyak video, tetapi masih ada Mail, Search, analytics, dan banyak layanan lain yang sangat dimuat. Karena itu, jaringan merupakan komponen penting.

- Apa yang perlu Anda ketahui untuk menjadi administrator sistem yang baik?

- Tentu saja, Linux. Banyak perusahaan komersial sekarang menggunakan OS ini. Pada dasarnya, di dalam perusahaan mereka mencoba untuk tidak menggunakan distribusi yang berbeda, semua orang menginginkannya menjadi satu, lebih mudah untuk memperbarui dan memelihara sistem. Setiap orang memiliki preferensi mereka sendiri untuk distribusi, kami menggunakan CentOS. Jadi, pertama-tama, Anda perlu tahu Linux, bagaimana dan apa yang diatur di sana, bagaimana komunikasi antarproses diatur, bagaimana semuanya dimuat dan bekerja.

Berikutnya adalah spesialisasi - kepada siapa yang lebih dekat dan apa yang ada dalam jiwa :-). Seseorang mengkhususkan diri dalam otomatisasi, seseorang di server web, seseorang di jaringan, seseorang di database, dan seseorang di teknologi cloud. Sebagai contoh, pada suatu waktu saya sangat menyukai database. Anda perlu memahami cara kerja aplikasi - untuk dapat mengkonfigurasinya, untuk memahami pro dan kontra dari menggunakan satu atau aplikasi lain dalam suatu tugas, dan, tentu saja, dapat memperbaikinya dengan sangat cepat jika terjadi masalah.

Contoh spesialisasi seperti itu: insinyur jaringan memahami protokol dan tahu di mana dan mana yang lebih baik untuk digunakan, mereka dapat mengkonfigurasi routing global dan lokal, mereka tahu bagaimana memastikan keandalan dan toleransi kesalahan jaringan.

Spesialis basis data tahu cara membuang, mereplikasi, membuat cadangan basis data untuk menyimpan informasi dengan andal dan memastikan kecepatan tinggi. Orang-orang ini tahu cara melihat rencana kueri, mereka tahu mengapa indeks diperlukan dan apa itu.

Tugas khas: untuk membahas mengapa permintaan dieksekusi untuk waktu yang lama, Anda perlu melihat paket dan melihat apakah ada masalah dengan memuat server (memori, prosesor, I / O).

- Menurut pendapat umum, admin disajikan sebagai pria dengan janggut besar di sweter yang diregangkan. Apakah sulit bagi Anda untuk bekerja dalam tim putra?

- Pertanyaan yang sulit, karena saya telah bekerja selama bertahun-tahun. Pertama, saya sudah terbiasa. Kedua, jika kita berbicara tentang industri secara keseluruhan, sudah ada beberapa gadis yang beroperasi.

Mitos seperti itu berasal dari zaman kuno, ketika banyak pekerjaan fisik diperlukan. Teman saya dan saya masih ingat bagaimana kami berdua mengeluarkan server multi-unit yang besar, berat, dan meletakkannya di lantai, karena kami tidak bisa lagi membawanya ke tempat khusus untuk pemeliharaan. Dan mereka duduk di lantai di tengah pusat data dengan obeng, ganti roda. Belum ada slide :-)

Sekarang tidak ada hal seperti itu. Kami bekerja di kantor yang nyaman di meja. Pekerjaan kami hari ini tidak berbeda dengan pekerjaan seorang programmer, yang juga tidak pernah murni maskulin: programmer wanita adalah kejadian yang cukup umum.

- Survei cepat kami. Apa laptop kamu?

- Apple.

- Mana yang lebih baik, Bash atau Perl?

- Bash.

- Startup atau perusahaan besar?

- Startup di perusahaan besar.

"Untuk apa kau tidak punya cukup uang?"

- Ke kapal pesiar.

- Jawaban yang bagus. Semua orang akan segera memahami tingkat gaji di Grup Mail.Ru.

- Tepat.

- ICQ atau TamTam?

- ICQ.

- "VK" atau "Teman Sekelas"?

- VK.

- Siapa idola kamu?

- Saya tidak punya idola. Saya percaya bahwa banyak orang di Internet Rusia dan asing telah melakukan cukup banyak untuk industri ini. Berkat mereka, itu berkembang dengan kecepatan seperti itu. Saya beruntung, dengan banyak dari mereka yang saya kenal secara pribadi.

- Sebut Rusia besar.

- Cukup banyak; lagi, saya khawatir saya tidak akan mencantumkan semua orang. Jika seseorang perlu dipilih secara pribadi, saya senang bahwa dalam hidup saya berhasil bekerja dengan Ilya Segalovich.

Source: https://habr.com/ru/post/id416849/


All Articles