Selama tiga belas tahun, kami telah mencari cara untuk menskalakan pengembangan sehingga semuanya bekerja dengan andal seiring pertumbuhannya dan, pada saat yang sama, fitur-fitur baru dirilis dengan cepat. Setelah tampaknya penting untuk mengganti nama kolom dalam database dengan mudah. Sekarang - saya harus mengubah seluruh arsitektur saat bepergian.
Ini adalah pos pengembangan tahunan ketiga untuk Black Friday, minggu puncak. Mengapa kita akhirnya berpikir bahwa kita hebat; apa yang mereka lakukan untuk ini; mengapa kami menemui kesulitan dan apa yang akan kami lakukan selanjutnya.
Ringkasan: dua tahun bekerja untuk alasan yang bagus
Untuk tahun kelima berturut-turut, beban di Mindbox kira-kira dua kali lipat setiap tahun. Pada November 2020, kami memproses 8,75 miliar permintaan API, dibandingkan dengan 4,48 miliar pada tahun sebelumnya. Puncaknya 400 ribu permintaan per menit. Mengirim 1,64 miliar email dan 440 juta notifikasi seluler. Setahun yang lalu, ada 1,1 miliar email, tetapi hampir tidak ada permintaan.
Dinamika jumlah surat per minggu Black Friday:
Menurut data kami, ini adalah tingkat beban pada permintaan API yang sebanding dengan hh.ru, dan pada beban pada database - dengan Avito. Sekitar sepertiga dari Yandex-Taxi berdasarkan permintaan per menit.
Pada 2018 dan 2019Selama bertahun-tahun kami telah menangani ini dengan buruk: klien menderita penolakan. Di penghujung tahun 2018 ini, saya mengharapkan perbaikan yang cepat dan mengharapkan roadmap bisnis yang selama ini baru setengah selesai. Pada 2019, saya memutuskan untuk diam tentang peta jalan, karena keandalan memburuk, kegagalan dimulai pada bulan September, dan pada Black Friday mereka berulang, meskipun banyak pekerjaan yang dilakukan.
Hari ini kita dapat menyimpulkan: kita telah belajar mengatasi pertumbuhan. Black Friday 2020 berlalu tanpa insiden yang memengaruhi lebih dari satu pelanggan. Ada dua kegagalan parsial jangka pendek karena infrastruktur eksternal yang tidak melanggar SLA. Sayangnya, ada keluhan dari beberapa klien terbesar, tetapi ini adalah satu cerita yang kami pahami, dan kami sedang mengerjakannya.
Selain itu, data dan ulasan subjektif pengguna menunjukkan tren peningkatan kualitas pembangunan dalam jangka panjang. Jumlah kerusakan - kesalahan kritis, kegagalan dan kasus kinerja yang tidak memuaskan - berkurang.
Grafik menunjukkan pelanggaran SLA internal (lebih ketat daripada yang eksternal), yang juga kami buat lebih ketat tahun ini:
Jumlah pelanggaran SLA internal oleh klien rata-rata
Kami berhasil sepenuhnya "menemukan kembali" pengembangan dalam dua tahun, terus tumbuh pada tingkat rata-rata 40% pendapatan per tahun (pada 2019 - 431 juta, pada 2020 - 618 juta) dan merilis fitur baru. Perasaan - tentang cara mengganti mesin mobil dengan kecepatan penuh.
Apa yang telah dilakukan dalam dua tahun:
- (LESS) , , .
- 50% , ( ) .
- SRE. SRE .
- , , .
- SLA .
- «-», .
Ini jauh dari semua yang direncanakan. Kami terus meningkatkan jumlah sumber daya yang dialokasikan untuk kualitas. Kami mengharapkan peningkatan kualitas lebih lanjut dan rilis fitur baru yang lebih cepat pada tahun 2021 dan seterusnya.
Omong-omong, kami secara teratur menulis tentang pembaruan pada produk dan mempertahankan halaman status dengan riwayat insiden .
Asal usul kesulitan: 2008-2018
Mindbox adalah produk dengan logika bisnis yang kompleks, sejak 2008 kami telah berkembang sebagai layanan untuk bisnis besar, dengan porsi biaya pengembangan lebih dari 30%. Dari sudut pandang arsitektural, itu adalah aplikasi monolitik tradisional, tetapi kualitas sangat tinggi: setiap hari kami merilis dan masih merilis beberapa pembaruan monolit.
Pada tahun 2014, pasar membuat kami beralih ke segmen yang lebih massal, termasuk e-commerce dan retail. Ini membutuhkan investasi dalam layanan pelanggan, penjualan dan pemasaran.
Perusahaan tidak pernah menarik investasi eksternal, selalu berkembang atas keuntungannya sendiri. Selain itu, di tahun 2017, enam bulan setelah saya menjadi CEO, kami menghadapi kekurangan uang, saya menjadi takut dan meningkatkan profitabilitas saya secara berlebihan. Semua ini menyebabkan penurunan biaya pengembangan hingga 24% dari pendapatan pada 2018-2019.
Pada saat yang sama, banyak fungsi yang dibutuhkan oleh pelanggan baru harus dirilis - dengan peningkatan beban yang cepat dan jumlah pelanggan. Kami mengatasi masalah simpanan produk dan arsitektur asli, serta desentralisasi - pembentukan tim produk otonom.
Sayangnya, keahlian teknis dari tim semacam itu tidak dapat mengimbangi pertumbuhan perusahaan, yang selanjutnya diperparah oleh batasan kemungkinan dalam arsitektur monolitik. Hutang teknologi menumpuk, teknologi yang digunakan sudah ketinggalan zaman, dan gaji di bawah pasar. Mempekerjakan insinyur menjadi semakin sulit, terlepas dari tantangan yang menantang dan budaya unik perusahaan. Pada 2018, jumlah pelanggan meningkat 10 kali lipat, keberhasilan produk menjadi jelas, serta masalah keandalan dan pengembangan secara umum.
Tindakan apa yang telah kami ambil
Proses dan sumber daya
Hipotesis pertama adalah sentralisasi: pada tahun 2019, LESS diperkenalkan - ini adalah saat beberapa tim mengerjakan satu proyek pada waktu yang sama. Kami mulai bersama-sama merancang epos dan bekerja dengan keandalan, kami berhasil meningkatkan prediktabilitas dan menemukan praktik desain yang berguna. Namun, setelah satu tahun, ketidakefisienan proses menjadi jelas: demotivasi dan tanggung jawab tim berkurang karena kurangnya rasa fitur "mereka", biaya manajemen yang tinggi, yang tidak disukai siapa pun.
Lebih dari satu tahun desain kolaboratif, visi arsitektur desentralisasi muncul yang akan memungkinkan setiap tim untuk bertanggung jawab atas layanan mikro terisolasi sambil terus mengirimkan satu produk ke pelanggan. Bersama dengan visinya, timbunan tugas muncul dan menjadi jelas bahwa infrastruktur harus dikerjakan dengan spesialis yang berdedikasi, tanpa memotongnya dengan peta jalan bisnis.
Kami setuju untuk mengalokasikan 30% dari sumber daya untuk hutang teknis secara berkelanjutan. Tim infrastruktur pertama dibentuk, dan tim otonom mulai dialokasikan kembali. Pada saat yang sama, sejumlah proses kolaborasi terpusat telah dipertahankan, terutama ditujukan untuk menjaga kualitas:
- rancangan,
- analisis cacat,
- pemodelan beban pada besi,
- demo dan status sinkronisasi.
Membuat arsitek dan tim bertanggung jawab atas metrik keandalan dan prediksi biaya server. Selain itu, kami mengalokasikan 30% di setiap tim untuk hutang teknis dan bug, sambil menunggu kelangsungan bisnis.
Pada tahun 2020, proses diselesaikan: tim infrastruktur kedua dibentuk, pengiriman disesuaikan. Pangsa sumber daya untuk tugas-tugas bisnis mulai tumbuh perlahan dari titik terendah sekitar 50%, dan pangsa bug mulai berkurang:
Alokasi sumber daya pengembangan berdasarkan tugas. Grafik ini tidak terlalu informatif, karena metrik yang andal dibuat relatif baru-baru ini, tetapi didukung oleh tayangan dari lapangan.
Selama waktu ini, kami belajar cara menyewa dan mengaktifkan SRE, memisahkannya dari DevOps dan TI kantor, membentuk proses tugas, dan menjelaskan peran tersebut.
Kekurangan insinyur berkurang dengan dua cara:
- Kami menciptakan sekolah pengembangan yang meluluskan 8-12 pengembang junior setahun. Ini adalah pengembang yang memiliki pengalaman dengan tumpukan kami, yang kemampuannya kami yakini. Saat ini, sekolah memiliki 2 tim yang terdiri dari 4 peserta pelatihan.
- Kami secara sistematis meningkatkan gaji untuk pengembangan, karena hasil bisnis memungkinkannya. Gaji rata-rata dalam pembangunan telah tumbuh dari 120 ribu rubel pada 2015 menjadi 170+ pada akhir 2020 dan terus bertambah. Ini memungkinkan kami merekrut beberapa senior baru yang kuat dan pimpinan teknologi. Porsi biaya pengembangan naik menjadi 28%, dan jumlah orang meningkat dari 27 menjadi 64.
Metrik, metrik, dan metrik otomatis
Dalam budaya kita, itu kebiasaan untuk mengelola data, bukan pendapat pribadi. Metrik yang efektif mungkin merupakan salah satu pertanyaan sulit yang tidak dapat dijawab langsung oleh metodologi manajemen pembangunan modern.
Kami mulai dengan mengotomatiskan empat metrik dari buku Percepatan dan mempercepat jalur pengiriman. Ini tidak memiliki efek langsung yang jelas. Tetapi pertukaran pengalaman dengan hh.ru dan Yandex-cloud mengarahkan kami ke otomatisasi metrik pelanggaran SLA dan pembentukan cacat otomatis. Di sini kami merasakan manfaat dan keterkaitan dengan upaya yang dilakukan. Grafik metrik ini dengan tren ada di awal posting.
Berhati-hatilah, tapi menurut saya kami adalah salah satu dari sedikit perusahaan di dunia yang memiliki API untuk klien yang memungkinkan Anda mendapatkan metrik ketersediaan komponen platform secara real time.
Metrik yang dijelaskan di atas untuk bagian bug dan utang teknis dalam tim juga tampaknya berguna. Selain itu, kami mempertimbangkan bagaimana tim memenuhi janji yang diberikan untuk sprint, dan pengembang memenuhi tenggat waktu untuk tugas harian dan mingguan.
Akhirnya, jajak pendapat triwulanan tanpa nama (teksnya telah meningkat sejak saat itu, tetapi inti jajak pendapat tidak berubah) dan peringkat tinggi di Habr-Karer menunjukkan penurunan kemalangan pembangunan. Ini menyangkut penilaian pendapatannya terkait pasar, kilang, dan eNPS (sejauh ini data hanya untuk dua kuartal).
Survei Pendapatan Pengembang :
Survei Perbaikan Pengembang: Pengembang eNPS:
Pada skala 1 sampai 10, seberapa besar kemungkinan Anda merekomendasikan Mindbox sebagai tempat bekerja?
Last but not least - teknologi
Semua ini memungkinkan untuk mengatur penulisan ulang produk monolitik - lebih dari 2 juta baris kode di IIS + ASP.NET + NLB / Windows Service / MS SQL - secara bersamaan ke semua arah:
- Microservice API dan backend, ketika satu permintaan klien ke API Gateway ditangani secara transparan oleh beberapa layanan mikro, termasuk permintaan sinkron (pola saga).
- Microfront-end, di mana bagian antarmuka terpisah dari aplikasi SPA backend yang dapat dihosting di repositori mereka sendiri, dengan pipeline tata letaknya sendiri.
- Transfer layanan mikro multi-tenant dari MS SQL ke penyimpanan terukur terdistribusi: Cassandra, lickhouse. Kafka, bukan RabbitMQ.
- Transfer aplikasi ke .NET Core, linux dan transfer parsial ke Managed Kubernetes "Yandex-cloud". Implementasi segera teknologi SRE dan DevOps modern: OctopusDeploy + Helm, Prometheus, Grafana, Graylog + Sentry, Amixr.IO.
Mungkin kami adalah salah satu klien Yandex Cloud yang paling banyak dimuat, jadi Nikita Prudnikov berbicara tentang penerapan kami dan bersama-sama mengatasi kesulitan CTO dengan Yandex di Yandex Scale 2020 .
Dalam artikel kami di Black Friday, Anda dapat membaca tentang pendekatan penskalaan utama kami menggunakan contoh komponen milis yang tidak rusak tahun lalu dan tidak merusak yang satu ini.
Rencana pengembangan lebih lanjut
Terlepas dari hasil yang dicapai, saya harus mengatakan bahwa kurang dari setengah dari apa yang direncanakan telah dilakukan. Di depan:
- Terus tingkatkan pendapatan pengembang dan rekrut pemimpin senior dan teknologi terbaik
- Tim ketiga dari sekolah pengembangan, yang akan memungkinkan perekrutan hingga 12 pengembang per tahun
- Terjemahan lanjutan dari aplikasi ke .NET, k8s dan Yandex-cloud, penskalaan otomatis, tata letak biru-hijau dengan rollback instan
- Bergerak menuju pembentukan insiden otomatis di halaman status, menyingkirkan positif SLA palsu
- Bermigrasi ke .NET 5, EF.Core dan PostgreSQL (dan pengembang ke MacBook baru)
- Isolasi beberapa potongan berskala besar dari monolit
Dorongan termotivasi untuk tumbuh NET-pengembang tehlidov dan SRE-spesialis untuk merespon kami tugas kita untuk hh.ru . Ini akan menarik, Anda bisa mendapatkan pengalaman unik di pasar dan melakukan banyak hal.
Platform peta jalan pada tahun 2021
Kami merasakan fondasi yang kokoh di bawah kaki kami, yang memberi kami harapan bahwa kami dapat kembali memenuhi janji peta jalan bisnis kami. Kami mencoba proses perencanaan desentralisasi selama satu tahun untuk pertama kalinya, tetapi saya akan dengan ceroboh membiarkan diri saya membentuk ekspektasi publik.
Tahun ini kami akan menambahkan ke platform:
- Pembuat skenario .
- Menyimpan dan melaporkan pesanan anonim
- Laporan lebih cepat di antarmuka ( seperti dalam kursus kami )
- Integrasi dengan BI
- Modul notifikasi push seluler baru, termasuk SDK baru
- Kemampuan untuk dengan cepat menghapus entitas apa pun, dengan mempertimbangkan ketergantungan satu sama lain
- Lebih banyak algoritme ML dan banyak peningkatan kualitas dari yang sudah ada
- Lebih banyak halaman dalam desain baru dengan respons antarmuka yang ditingkatkan
- Kustomisasi integrasi dan mekanika standar yang disederhanakan
Rencana untuk tahun 2022 lebih ambisius, tetapi saya berharap dapat menulis tentangnya dalam satu tahun, jika optimismenya dapat dibenarkan.
Terima kasih
Seperti kisah sukses klien, yang satu ini adalah manfaat dari orang-orang tertentu yang saya ucapkan terima kasih:
Nikita Prudnikov, CTO, atas visi, konsistensi, dan pemerasan sistematis.
Roman Ivonin, Arsitek Utama, untuk kesabaran, pembangunan tim, tanggung jawab luas, kepemimpinan informal dan malam tanpa tidur.
Igor Kudrin, CIO, atas dasar keahlian SRE, visi dan keselamatan segalanya ketika tidak ada yang tahu caranya.
Rostislav, Leonid, Dmitry, Mitya, Ilya, two Artyoms, Alexei, Sergey, Nikolai, Ivan, Slava, Zhenya dan pengembang, produk, pimpinan teknologi, dan SRE yang peduli lainnya yang membuat semua ini menjadi kenyataan. Maaf jika saya tidak menyebut siapa pun.
Terima kasih khusus kepada klien yang bertahan, terlepas dari kenyataan bahwa kami gagal, dan memberikan kesempatan untuk meningkat. Kami akan berusaha semaksimal mungkin untuk membuatnya menjadi lebih baik.