Infrastruktur perusahaan sebagai produk

Infrastruktur adalah tempat kerja dan keuntungan bisnis TI bergantung. Semua proses yang terjadi dengan kode dari komputer pengembang ke produksi tergantung pada operasi server, perangkat lunak, dan layanan eksternal yang tidak terputus. Jika infrastruktur tidak berfungsi sebagaimana mestinya, bisnis kehilangan untung.

Startup tidak terlalu memperhatikan infrastruktur - mereka harus memotong produk sampai investor kehabisan uang. Perusahaan-perusahaan besar tidak lagi sanggup melakukannya - kami memiliki ribuan tugas di sini, kami perlu bekerja.

Memahami bahwa infrastruktur perusahaan IT juga merupakan produk, bahwa ia memiliki tujuan, bahwa perlu untuk mempertimbangkan biaya dan melacak metrik, sering kali tidak tercapai.


Apakah Anda tahu berapa biaya infrastruktur Anda: server, perangkat lunak, layanan eksternal? Menurut Anda berapa biayanya, berdasarkan metrik apa? Berapa banyak Anda akan kehilangan jika sesuatu jatuh atau tidak ada cadangan? Artyom Naumenko (@entsu) dari Skyeng tahu jawaban untuk pertanyaan-pertanyaan ini. Dia bekerja baik di perusahaan dengan dua pengembang di negara bagian, dan di perusahaan dengan seribu karyawan. Dia saat ini mengelola infrastruktur di Skyeng dan, pada saat yang sama, pusat pembelajaran anak-anak Skyeng. Artem akan memberi tahu bagaimana perusahaan membangun infrastruktur, bagaimana mereka menghasilkan uang, dan kesalahan apa yang seharusnya tidak dilakukan.

Tentang perusahaan


Skyeng adalah perusahaan muda, baru berusia 6 tahun. Namun selama ini telah tumbuh 3 kali setiap tahun.



Ini berarti infrastrukturnya juga tumbuh tiga kali setiap tahun. Saat ini kami memiliki 100 server, 300 dalam setahun, dan 900 dalam dua. Ini tidak mudah, kami bekerja keras untuk memastikan pertumbuhan tersebut.

Skyeng adalah perusahaan IT. Perusahaan masih muda, belum ada banyak warisan, semuanya standar untuk tumpukan PHP:

  • PHP
  • Sudut
  • PostgreSQL
  • Linux tempat semuanya berputar.

Sekitar seratus pengembang. Perusahaan ini tumbuh dan pada akhir tahun akan ada lebih banyak.



Sebagian besar layanan kami ditulis oleh kami, dan seluruh bisnis perusahaan berputar pada infrastrukturnya sendiri. Ini dipantau oleh tim infrastruktur yang terdiri dari 6 orang. Kami menyediakan semua proses yang terjadi dengan kode dari komputer pengembang ke produksi. Kode dikembangkan pada mesin dan server virtual kami, penyebaran - dengan bantuan Jenkins kami yang terkonfigurasi dan alat penyebaran kami, operasi produksi juga ada di server kami, yang kami kelola.

Tujuan perusahaan adalah tumbuh 7 kali dalam 2 tahun. Infrastruktur harus tumbuh serupa. Untuk mencapai tujuan, setiap anggota tim devops bekerja seperti lembu. Setiap tahun kita harus 3 kali lebih baik dari tahun lalu, dan 7 kali lebih baik di masa depan. Di Skyeng, tidak ada yang tertarik pada kisah indah yang "mencoba, tetapi gagal." Hasilnya penting, bukan prosesnya.

Prinsip pembangunan infrastruktur


Bisnis dari setiap perusahaan IT bekerja pada infrastruktur. Jika tidak berhasil, bisnisnya tidak berfungsi, baik itu Yandex, Amazon atau Skyeng. Kami menyadari hal ini, oleh karena itu hal pertama yang penting untuk infrastruktur keren adalah menetapkan tujuan . Kedengarannya seperti pidato oleh Tony Robbins, tetapi tanpa tujuan, tidak ada yang akan berhasil.

Sasaran harus ditetapkan karena dua alasan.

  • Jika Anda memiliki tujuan, Anda akan bergerak ke sana.
  • Jika tidak ada tujuan, maka tidak ada tempat untuk pergi. Bahkan jika Anda datang ke suatu tempat, Anda tidak akan bisa mendapatkan tinggi dari tujuan yang dicapai.

Jika tidak ada tujuan, tidak mungkin tercapai.

Masalah perusahaan


Menetapkan tujuan saja tidak cukup. Tujuan perusahaan adalah tumbuh 7 kali dalam 2 tahun. Akan ada masalah selama pertumbuhan. Mereka bervariasi, tergantung pada ukuran dan jenis perusahaan.

Jenis perusahaan dan orang pertama adalah startup . Pada gambar di bawah ini, "startup khas" - rakit dan tim kecil yang mencoba untuk berenang di suatu tempat. Keuntungan dari startup adalah bahwa setiap anggota tim memahami ke mana tim bergerak, siapa yang melakukan apa, dan apa yang harus dia lakukan untuk mencapai tujuan bersama.



Masalah dengan startup adalah kurangnya uang. Ketika banyak tugas jatuh pada devops, dia tidak punya waktu dan bertanya pada dirinya sendiri seorang asisten. Biasanya dia mendapat jawabannya: β€œKenapa? Anda berhasil, semua peraturan - teruskan! "

Jenis berikutnya adalah kapal besar . Beberapa anggota awak kapal tidak melihat di mana kapal itu berlayar. Mereka melakukan fungsi kecil mereka, misalnya, mereka melemparkan batu bara ke tungku, dan mereka tidak mengerti apa yang terjadi secara global.



Masalah utama dengan kapal adalah semakin banyak tugas yang dibutuhkan. Seratus pelanggan, untuk setiap masalah, tidak jelas bagaimana memprioritaskan, gambaran keseluruhan kabur, tapi kami sedang "bekerja"! Waktu tidak pernah cukup, dan semakin banyak tugas yang diperlukan. Sebuah tim tidak akan pernah dapat membangun konveyor yang melemparkan batu bara ke tungku untuk mengerjakan tugas-tugas penting.

Tipe ketiga adalah pemimpin . Masalah utama bagi manajer infrastruktur adalah server mahal, infrastruktur mahal, dan kurangnya pemahaman tentang bagaimana biaya infrastruktur mempengaruhi pendapatan bisnis secara umum. Pemimpin perlu entah bagaimana menjawab pertanyaan tentang mengapa ada begitu banyak jutaan server, apakah kita akan berbohong lebih sedikit jika kita membayar lebih banyak, dan apa yang akan terjadi jika kita membayar lebih sedikit.


Tujuan infrastruktur


Saya akan menjelaskan tujuan apa yang ada di Skyeng yang kami tetapkan untuk infrastruktur kami dalam konteks tujuan global perusahaan, dan bagaimana kami mencapainya. Infrastruktur memiliki 4 tujuan.

Pantau anggaran . Perusahaan adalah struktur komersial untuk menghasilkan uang, jadi kita harus menghitungnya.

Selesaikan tugas dengan cepat . Mereka tidak menaikkan server tepat waktu, layanan baru perusahaan tidak akan mulai dan tidak akan menghasilkan uang. Cadangan tidak dipulihkan tepat waktu - lagi, sesuatu tidak akan berfungsi, dan perusahaan akan kehilangan keuntungan.

Kenyamanan para pengembang . Item ini membutuhkan penjelasan terpisah. Tahun lalu, Skyeng menghabiskan 600 juta rubel untuk pengembangan. Jika kita, sebagai infrastruktur, meningkatkan kecepatan pengembang setidaknya 1%, kita akan mendapatkan 6 juta.Jika Anda menempatkan dua orang pada waktu penuh, yang akan meningkatkan produktivitas sebesar 1%, itu akan menguntungkan.

Hasil jangka panjang . Kita seharusnya tidak berusaha sekali, melakukan sesuatu yang keren sehingga semua orang bahagia, dan kemudian semuanya akan runtuh. Apa yang kita lakukan harus bekerja untuk waktu yang lama.

Agar ini berfungsi, metrik perlu diciptakan. Mereka harus bisa diukur, kalau tidak itu bukan tujuan, tetapi omong kosong. Tujuan harus dinyatakan dalam angka dan grafik.

Mari kita pertimbangkan barang-barang dengan lebih detail.

Anggaran


Mengukur infrastruktur oleh perusahaan adalah bagian mana dari pengeluaran perusahaan untuk infrastruktur.



Skyeng adalah sekolah, dan nilai utamanya adalah pelajaran. Pelajaran rata-rata biaya 800 rubel. Dari jumlah tersebut, 12 masuk ke infrastruktur: server dan devops.



Persentase infrastruktur menurun, kami sedang mengusahakannya. Ini menguntungkan kita, bisnis, dan pelanggan. Anda dapat mengambil server murah, jangan membuat cadangan dan bahkan menjatuhkan jadwal ini. Tapi ini salah, perlu untuk mempertimbangkan tidak hanya biaya infrastruktur, tetapi biaya infrastruktur dan kerugian yang diperkirakan dari jatuh.

Untuk setiap layanan, kami mempertimbangkan berapa banyak uang per jam yang hilang dari kejatuhannya. Kami menyimpan catatan terperinci tentang kapan dan layanan apa yang berbohong, dan seberapa besar kerugian kami dalam hal ini.


Jadwal kerugian dari jatuh selama setahun terakhir.

Kerugian terbanyak di kuartal kedua 2018 - halo bagi Roskomnadzor! Pengeluaran infrastruktur tahun lalu adalah 20 juta, pengeluaran untuk jatuh - 5 juta Jika kita telah memesan semuanya, itu akan menyelamatkan kita dari Roskomnadzor, tetapi kita masih akan berada di zona merah sebesar 15 juta.

Tidak menguntungkan bagi bisnis untuk menduplikasi semuanya. Seseorang harus berpikir apa yang harus diduplikasi dan apa yang tidak.

Kami menduplikasi layanan yang biaya server atau database tambahan lebih rendah dari risiko yang diperkirakan dari jatuh.

Lakukan dengan cepat


Kami mengukur persentase tugas yang diselesaikan pada hari pengaturan. Infrastruktur hadir dengan banyak tugas yang perlu diselesaikan di sini dan sekarang. Tim lain yang tidak dapat melakukan pekerjaan mereka bergantung pada ini. Tugas besar yang memakan waktu berminggu-minggu dianggap terpisah.


Jadwalkan tugas pada hari pengaturan.

Menurut jadwal, probabilitas menyelesaikan tugas pada hari pengaturan adalah sekitar 80%. Kami melihat grafik ini dan percaya bahwa semuanya keren. Tetapi tim lain mungkin tidak berpikir begitu dan mengevaluasi secara berbeda. Karena itu, kami melakukan survei terhadap tim lain.


Contoh jajak pendapat.

Kami melakukan survei melalui formulir Google yang biasa dengan pertanyaan. Pengembang dan pelanggan kami yang lain merespons mereka secara teratur.


Hasil survei tentang kecepatan infrastruktur.

Keadaan saat ini dijelaskan dengan baik oleh jajak pendapat, tetapi tidak masa depan. Untuk menilai kemungkinan situasi di masa mendatang, kami mengukur jumlah tugas yang dilakukan menggunakan permintaan tarik. Inilah yang akan bermanfaat dalam satu atau dua tahun.

Enam bulan lalu, kami memutuskan bahwa kami akan pergi ke "infrastruktur sebagai kode." Di sini kita mengukur semua permintaan ke infrastruktur: mengisi dump atau sepotong log, memperbaiki titik nginx pada prod atau membuat server baru. Ini semua permintaan, dan kami mengevaluasi semuanya dengan jumlah permintaan tarik. Di masa depan, kami ingin setiap permintaan diselesaikan dengan bantuan permintaan tarik atau agar kami tidak diminta.

Kita tahu bahwa pendekatan "infrastruktur sebagai kode" memberikan tiga bonus utama:

  • pengurangan biaya perubahan;
  • peningkatan laju perubahan;
  • pengurangan risiko.

Kita membutuhkan ketiganya, jadi kita bergerak dengan cara ini dan mengukur seberapa dekat kita.



Untuk log ada sistem visualisasi, untuk mengeluarkan akses ada Terraform. Anda dapat membuat sistem di mana semuanya akan otomatis. Idealnya, bagan ini harus 100%. Ketika panggilan dibuat menggunakan kode, kami dapat dengan cepat menjalankannya dan menyebarkannya ke infrastruktur lain dengan cepat.

Nyaman bagi pengembang


Ini penting bagi Skyeng. Kami sekarang memiliki 100 pengembang, pada akhir tahun akan ada 120 pengembang. Penting agar mereka bekerja secara efisien. Kami ingin mempekerjakan orang karena suatu alasan, kami membutuhkan mereka yang akan meningkatkan perusahaan.

Satu-satunya dan metrik utama untuk pengembang adalah hasil survei kepuasan dengan tim infrastruktur.


Secara umum, semuanya OK.

Kebanyakan menghargai kita dengan baik. Tetapi jika Anda bertanya seberapa puas mereka dengan lingkungan pengembangan, maka semuanya tidak begitu menyenangkan.



Lingkungan pengembangan adalah sakit kepala kita. Ini adalah titik pertumbuhan yang perlu ditingkatkan. Oleh karena itu, kami secara pribadi mewawancarai karyawan yang menjawab yang terburuk: apa masalahnya, apa yang melambat atau tidak berhasil baginya? Mengetahui apa yang terjadi dapat meningkatkan banyak hal.

Sampai Anda tahu apa yang terjadi, Anda tidak dapat mengubah apa pun.

Hasil jangka panjang


Metrik kami mana pun dapat ditingkatkan dengan hanya berkonsentrasi padanya. Misalnya, untuk meningkatkan persentase tugas yang diselesaikan pada hari yang sama, Anda dapat membatalkan semuanya dan menyelesaikan hanya tugas yang datang. Anda dapat melakukan semua tugas menggunakan kode.

Misalnya, di kota tertentu "N" semua upaya dihabiskan untuk pengembangan jalan. Mereka membuat jalur multi-jalur yang datar, lebar, dan lebar di kota. Ini keren, tahun kedua. Tetapi semua daerah lain mengalami degradasi: tidak ada lingkungan yang dapat diakses, pohon ditebang, ada lebih banyak mobil, tidak ada tempat parkir yang memadai, dan lingkungan telah meninggalkan kota di sepanjang jalan ini. Dalam 5-10 tahun, taksi dan hyperloop otonom sudah akan muncul di kota tetangga, tetapi di sini masih ada jalan yang mulus. Jelas bahwa ini adalah jalan menuju ke mana-mana.

Kita seharusnya tidak membiarkan ini, kita perlu melihat ke depan. Oleh karena itu, kami mengukur jumlah waktu yang kami habiskan untuk pengembangan dan dukungan.



Grafik menunjukkan bahwa dalam beberapa bulan terakhir hanya sedikit waktu yang dihabiskan untuk pengembangan. Bagi saya, sebagai seorang pemimpin, ini adalah tanda bahwa orang diperlukan atau proses otomatisasi. Menurut jadwal, saya bahkan dapat menghitung berapa bulan semua sumber daya akan pergi untuk mendukung, ketika kita tidak akan tepat waktu dan akan ada kehancuran.

Tugas yang Menguntungkan


Kami menetapkan tujuan dan memikirkan metrik, tetapi sampai kami mulai menerapkannya dengan tangan kami, tidak ada yang akan berubah. Anda perlu bukan hanya sesuatu, tetapi tugas yang paling menguntungkan dalam hal metrik dan waktu.

Seiring waktu, semuanya menyederhanakan.

Dua tugas dapat dibandingkan dalam waktu: yang pertama akan memakan waktu seminggu, yang kedua - 3 jam. Itu tidak tergantung dari departemen mana tugas itu berasal. Metrik lebih rumit - ada banyak. Bagaimana cara menghitung tugas mana yang lebih menguntungkan untuk dilakukan: yang pertama atau kedua, jika yang satu mengoptimalkan beberapa metrik dan lainnya yang lain?

Bagi kami sendiri, kami memutuskannya sederhana - kami datang dengan unit universal yang menjelaskan tugas apa pun. Unit universal kami adalah rubel . Kami mengevaluasi manfaat dari tugas apa pun dengan keuntungan yang akan dihasilkan dan dibagi pada saat dibutuhkan untuk menyelesaikan tugas ini. Jadi kami mengevaluasi setiap tugas dalam hal metrik (rubel) dan waktu.


Tugas triwulanan kami.

Pada tangkapan layar di bawah, dua kolom terakhir menunjukkan berapa banyak uang yang akan kita hasilkan untuk tugas itu dan berapa banyak waktu yang akan kita habiskan untuk itu. Tim infrastruktur menghasilkan uang dengan meningkatkan kondisi untuk pengembang, mengoptimalkan proses di perusahaan dan pengoperasian server. Kami beralih ke Docker bukan karena itu keren, tetapi karena kami pikir itu menguntungkan.



Metrik tambahan yang kami ukur.

Uang muka:

  • % dukungan;
  • % tugas dengan PR;
  • % tugas ditutup per hari.

Tertunda:

  • % dari laba perusahaan;
  • kerugian karena jatuh;
  • ulasan pengembang.

Ini hanya bagian dari metrik, kami memiliki lebih dari itu.

Tugas Kami Tidak Mengevaluasi


Kami tidak mengevaluasi bug. Jika kami mengambil semacam sistem untuk mendukung dan mendukungnya, maka kami memperbaiki bug hanya karena mereka tidak seharusnya ada di sana.

Hal yang sama berlaku untuk dukungan. Kami mengukur secara umum berapa banyak waktu yang dihabiskan untuk dukungan, dan kami tidak mengizinkannya terlalu banyak. Kami mengevaluasi setiap sistem secara keseluruhan untuk manfaat atau bahayanya. Tugas yang lebih mudah dilakukan atau sangat mendesak, tidak kami evaluasi. Semua yang saya bicarakan tidak berlaku untuk mereka - kami hanya melakukannya.

Mengapa bermanfaat dan penting untuk mengevaluasi tugas


Hadiah dan prestasi . Dengan bisnis Anda selalu perlu berbicara dalam bahasa uang. Dia hanya mengerti uang. Jika Anda mengatakan bahwa Anda memiliki proyek, Anda berhasil, itu akan menghasilkan 5 juta, dan meminta satu juta hadiah per tim - mereka akan setuju dengan Anda. Untuk bisnis, ini bisa dimengerti.

Mempekerjakan Jangan menawarkan bisnis untuk merekrut karyawan dan memperkenalkan teknologi baru, tetapi tawarkan untuk menghasilkan uang bersama. Maka dia pasti akan bertemu Anda. Minimal, diskusi akan dimulai tidak di sepanjang jalan "Apakah Anda punya waktu atau tidak punya waktu, apakah Anda memerlukan seseorang atau tidak", tetapi seberapa keren proyek yang Anda butuhkan seseorang, akan dia kelola, dan akankah proyek benar-benar menghasilkan jutaan. Percakapan akan mengarah ke arah yang berbeda, dan Anda sendiri akan mengerti sebelumnya apakah proyek ini sepadan dengan biayanya atau lebih mudah membuangnya dan mencari yang lain?

Optimalisasi biaya . Jika kita mengerti berapa banyak uang yang dihabiskan, kita dapat dengan mudah menghitungnya dan mengoptimalkan pengeluaran.

Keputusan administratif . Item ini baru saya sadari. Infrastruktur mulai tumbuh dan saya memutuskan untuk membagi tim menjadi sub-perintah. Timbul pertanyaan tentang bagaimana melakukan ini dengan tepat, dengan tujuan kepegawaian lebih lanjut. Solusi muncul berdasarkan metrik - membagi semua metrik infrastruktur kami menjadi blok, dan setiap tim bertanggung jawab atas metriknya sendiri. Saya mendapat 3 sub perintah. Untuk masing-masing, bidang tanggung jawab bersama dapat dipahami dan semua peserta di dalamnya memahami apa yang menjadi tanggung jawab pribadi mereka. Ini adalah bidang tanggung jawab yang bisa dipahami.

Untuk membuatnya keren


  • Tetapkan tujuan - tempat tanpa itu.
  • Hancurkan target menjadi metrik dan ukur.
  • Mengevaluasi tugas dan menyelesaikan yang paling keren.

Maka Anda pasti akan sukses!

Di DevOps Conf 2019 , kita akan berbicara tentang "infrastruktur sebagai kode" secara terpisah. Masa depan pendekatan, pola Terraform, penyebaran dan manajemen infrastruktur BareMetal dan Kubernet adalah empat makalah tentang topik ini. Sebuah konferensi yang mempertemukan proses dan teknologi akan diadakan di Moskow pada 30 September dan 1 Oktober . Jadwal sudah siap, Anda dapat mempelajari program , abstrak atau memesan tiket .

Berlangganan buletin dan saluran Telegram dan tetap pantau untuk berita dan laporan baru.

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


All Articles