Sekarang topik DevOps sedang hangat-hangatnya. Integrasi Berkelanjutan dan Saluran Pengiriman semua orang menerapkannya. Namun sebagian besar tidak selalu memberikan perhatian yang cukup untuk memastikan keandalan sistem informasi di berbagai tahap CI/CD Pipeline. Dalam artikel ini saya ingin berbicara tentang pengalaman saya dalam mengotomatiskan pemeriksaan kualitas perangkat lunak dan menerapkan kemungkinan skenario untuk “penyembuhan mandiri”.
Saya bekerja sebagai insinyur di departemen manajemen layanan TI sebuah perusahaan . Bidang keahlian inti saya adalah penerapan berbagai sistem pemantauan kinerja dan ketersediaan aplikasi. Saya sering berkomunikasi dengan pelanggan TI dari segmen pasar yang berbeda mengenai isu terkini mengenai pemantauan kualitas layanan TI mereka. Tujuan utamanya adalah meminimalkan waktu siklus rilis dan meningkatkan frekuensi rilis. Tentu saja, semuanya baik-baik saja: lebih banyak rilis - lebih banyak fitur baru - lebih banyak pengguna yang puas - lebih banyak keuntungan. Namun kenyataannya, segala sesuatunya tidak selalu berjalan dengan baik. Dengan tingkat penerapan yang sangat tinggi, pertanyaan segera muncul mengenai kualitas rilis kami. Bahkan dengan pipeline yang sepenuhnya otomatis, salah satu tantangan terbesarnya adalah memindahkan layanan dari pengujian ke produksi tanpa memengaruhi waktu aktif aplikasi dan pengalaman pengguna.
Berdasarkan hasil berbagai percakapan dengan pelanggan, saya dapat mengatakan bahwa kontrol kualitas rilis, masalah keandalan aplikasi, dan kemungkinan "penyembuhan sendiri" (misalnya, mengembalikan ke versi stabil) di berbagai tahap CI /CD pipeline adalah salah satu topik yang paling menarik dan relevan.
Baru-baru ini saya sendiri bekerja di sisi pelanggan - di layanan dukungan perangkat lunak aplikasi perbankan online. Arsitektur aplikasi kami menggunakan sejumlah besar layanan mikro yang ditulis sendiri. Hal yang paling menyedihkan adalah tidak semua pengembang dapat mengatasi tingginya laju pengembangan; kualitas beberapa layanan mikro menurun, sehingga menimbulkan julukan lucu bagi mereka dan pembuatnya. Ada cerita tentang bahan apa produk ini dibuat.
"Rumusan masalah"
Frekuensi rilis yang tinggi dan banyaknya layanan mikro membuat sulit untuk memahami pengoperasian aplikasi secara keseluruhan, baik pada tahap pengujian maupun pada tahap operasional. Perubahan terjadi terus-menerus dan sangat sulit dikendalikan tanpa alat pemantauan yang baik. Seringkali, setelah rilis malam di pagi hari, pengembang duduk seperti di atas tong mesiu dan menunggu hingga tidak ada yang rusak, meskipun semua pemeriksaan berhasil pada tahap pengujian.
Ada satu hal lagi. Pada tahap pengujian, fungsionalitas perangkat lunak diperiksa: implementasi fungsi utama aplikasi dan tidak adanya kesalahan. Penilaian kinerja kualitatif tidak ada atau tidak memperhitungkan seluruh aspek aplikasi dan lapisan integrasi. Beberapa metrik mungkin tidak diperiksa sama sekali. Akibatnya, ketika terjadi kerusakan di lingkungan produksi, departemen dukungan teknis hanya mengetahuinya ketika pengguna sebenarnya mulai mengeluh. Saya ingin meminimalkan dampak perangkat lunak berkualitas rendah terhadap pengguna akhir.
Salah satu solusinya adalah dengan menerapkan proses pemeriksaan kualitas perangkat lunak di berbagai tahapan Pipeline CI/CD, dan menambahkan berbagai skenario untuk memulihkan sistem jika terjadi keadaan darurat. Kami juga ingat bahwa kami memiliki DevOps. Bisnis berharap untuk menerima produk baru secepat mungkin. Oleh karena itu, semua pemeriksaan dan skrip kami harus diotomatisasi.
Tugas ini dibagi menjadi dua komponen:
- pengendalian kualitas kumpulan pada tahap pengujian (untuk mengotomatiskan proses penangkapan kumpulan berkualitas rendah);
- kontrol kualitas perangkat lunak di lingkungan produksi (mekanisme untuk mendeteksi masalah secara otomatis dan kemungkinan skenario untuk penyembuhan mandiri).
Alat untuk memantau dan mengumpulkan metrik
Untuk mencapai tujuan yang telah ditetapkan, diperlukan sistem pemantauan yang dapat mendeteksi masalah dan mentransfernya ke sistem otomasi di berbagai tahapan pipeline CI/CD. Ini juga akan menjadi hal yang positif jika sistem ini menyediakan metrik yang berguna untuk berbagai tim: pengembangan, pengujian, pengoperasian. Dan sungguh luar biasa jika ini juga untuk bisnis.
Untuk mengumpulkan metrik, Anda dapat menggunakan serangkaian sistem yang berbeda (Prometheus, ELK Stack, Zabbix, dll.), tetapi menurut saya, solusi kelas APM paling cocok untuk tugas-tugas ini (), yang dapat sangat menyederhanakan hidup Anda.
Sebagai bagian dari pekerjaan saya di layanan dukungan, saya mulai melakukan proyek serupa menggunakan solusi kelas APM dari Dynatrace. Sekarang, bekerja untuk integrator, saya mengetahui pasar sistem pemantauan dengan cukup baik. Pendapat subjektif saya: Dynatrace paling cocok untuk menyelesaikan masalah seperti itu.
Dynatrace memberikan tampilan horizontal setiap operasi pengguna pada tingkat granular hingga tingkat eksekusi kode. Anda dapat melacak seluruh rantai interaksi antara berbagai layanan informasi: dari tingkat front-end aplikasi web dan seluler, server aplikasi back-end, bus integrasi hingga panggilan spesifik ke database.
. Konstruksi otomatis semua ketergantungan antar komponen sistem
. Deteksi otomatis dan konstruksi jalur operasi layanan
Kami juga ingat bahwa kami perlu berintegrasi dengan berbagai alat otomatisasi. Di sini solusinya memiliki API praktis yang memungkinkan Anda mengirim dan menerima berbagai metrik dan peristiwa.
Selanjutnya, mari kita beralih ke tampilan yang lebih detail tentang cara mengatasi masalah ini menggunakan sistem Dynatrace.
Tugas 1. Otomatisasi kendali mutu rakitan pada tahap pengujian
Tantangan pertama adalah menemukan masalah sedini mungkin dalam alur pengiriman aplikasi. Hanya pembuatan kode yang "baik" yang dapat mencapai produksi. Untuk melakukan ini, saluran pipa Anda pada tahap pengujian harus menyertakan monitor tambahan untuk memeriksa kualitas layanan Anda.
Mari kita lihat langkah demi langkah cara menerapkan dan mengotomatiskan proses ini:
Gambar tersebut menunjukkan alur langkah-langkah pengujian kualitas perangkat lunak otomatis:
- penerapan sistem pemantauan (pemasangan agen);
- mengidentifikasi peristiwa untuk menilai kualitas perangkat lunak Anda (metrik dan nilai ambang batas) dan mentransfernya ke sistem pemantauan;
- pembuatan uji beban dan kinerja;
- mengumpulkan data kinerja dan ketersediaan dalam sistem pemantauan;
- transfer data pengujian berdasarkan peristiwa penilaian kualitas perangkat lunak dari sistem pemantauan ke sistem CI/CD. Analisis otomatis majelis.
Langkah 1. Penerapan sistem pemantauan
Pertama, Anda perlu menginstal agen di lingkungan pengujian Anda. Pada saat yang sama, solusi Dynatrace memiliki fitur yang bagus - solusi ini menggunakan agen universal OneAgent, yang diinstal pada instance OS (Windows, Linux, AIX), secara otomatis mendeteksi layanan Anda dan mulai mengumpulkan data pemantauan pada layanan tersebut. Anda tidak perlu mengonfigurasi agen terpisah untuk setiap proses. Situasi serupa akan terjadi pada platform cloud dan container. Pada saat yang sama, Anda juga dapat mengotomatiskan proses instalasi agen. Dynatrace sangat cocok dengan konsep "infrastruktur sebagai kode" (): Ada skrip dan instruksi siap pakai untuk semua platform populer. Anda menyematkan agen ke dalam konfigurasi layanan Anda, dan saat Anda menyebarkannya, Anda segera menerima layanan baru dengan agen yang sudah berfungsi.
Langkah 2: Tentukan peristiwa kualitas perangkat lunak Anda
Sekarang Anda perlu memutuskan daftar layanan dan operasi bisnis. Penting untuk mempertimbangkan dengan tepat operasi pengguna yang penting bagi bisnis untuk layanan Anda. Di sini saya merekomendasikan untuk berkonsultasi dengan analis bisnis dan sistem.
Selanjutnya, Anda perlu menentukan metrik mana yang ingin Anda sertakan dalam tinjauan untuk setiap level. Misalnya, ini bisa berupa waktu eksekusi (dibagi menjadi rata-rata, median, persentil, dll.), kesalahan (logis, layanan, infrastruktur, dll.) dan berbagai metrik infrastruktur (tumpukan memori, pengumpul sampah, jumlah thread, dll.).
Untuk otomatisasi dan kemudahan penggunaan oleh tim DevOps, muncul konsep “Monitoring as Code”. Yang saya maksud dengan ini adalah pengembang/penguji dapat menulis file JSON sederhana yang mendefinisikan metrik jaminan kualitas perangkat lunak.
Mari kita lihat contoh file JSON tersebut. Objek dari Dynatrace API digunakan sebagai pasangan kunci/nilai (deskripsi API dapat ditemukan di sini ).
{
"timeseries": [
{
"timeseriesId": "service.ResponseTime",
"aggregation": "avg",
"tags": "Frontend",
"severe": 250000,
"warning": 1000000
},
{
"timeseriesId": "service.ResponseTime ",
"aggregation": "avg",
"tags": "Backend",
"severe": 4000000,
"warning": 8000000
},
{
"timeseriesId": "docker.Container.Cpu",
"aggregation": "avg",
"severe": 50,
"warning": 70
}
]
}File tersebut adalah serangkaian definisi deret waktu:
- timeseriesId – metrik yang diperiksa, misalnya, Waktu Respons, Jumlah kesalahan, Memori yang digunakan, dll.;
- agregasi - tingkat agregasi metrik, dalam kasus kami rata-rata, tetapi Anda dapat menggunakan apa pun yang Anda perlukan (rata-rata, min, maks, jumlah, hitungan, persentil);
- tag – tag objek dalam sistem pemantauan, atau Anda dapat menentukan pengidentifikasi objek tertentu;
- parah dan peringatan – indikator ini mengatur nilai ambang batas metrik kami; jika nilai pengujian melebihi ambang batas parah, maka pembangunan kami ditandai sebagai tidak berhasil.
Gambar berikut menunjukkan contoh penggunaan ambang batas tersebut.
Langkah 3: Pembuatan Beban
Setelah kami menentukan tingkat kualitas layanan kami, kami perlu membuat beban uji. Anda dapat menggunakan alat pengujian apa pun yang Anda sukai, seperti Jmeter, Selenium, Neotys, Gatling, dll.
Sistem pemantauan Dynatrace memungkinkan Anda menangkap berbagai metadata dari pengujian Anda dan mengenali pengujian mana yang termasuk dalam siklus rilis dan layanan mana. Disarankan untuk menambahkan header tambahan ke permintaan pengujian HTTP.
Gambar berikut menunjukkan contoh di mana, dengan menggunakan header tambahan X-Dynatrace-Test, kami menunjukkan bahwa pengujian ini berkaitan dengan pengujian operasi penambahan item ke keranjang.
Saat Anda menjalankan setiap pengujian beban, Anda mengirimkan informasi kontekstual tambahan ke Dynatrace menggunakan Event API dari server CI/CD. Dengan cara ini, sistem dapat membedakan berbagai pengujian.
. Peristiwa dalam sistem pemantauan tentang dimulainya pengujian beban
Langkah 4-5. Kumpulkan data kinerja dan transfer data ke sistem CI/CD
Bersamaan dengan pengujian yang dihasilkan, suatu peristiwa ditransmisikan ke sistem pemantauan tentang perlunya mengumpulkan data untuk memeriksa indikator kualitas layanan. Ini juga menentukan file JSON kami, yang menentukan metrik utama.
Peristiwa tentang perlunya memeriksa kualitas perangkat lunak yang dihasilkan di server CI/CD untuk dikirim ke sistem pemantauan
Dalam contoh kita, acara pemeriksaan kualitas disebut perfSigDynatraceLaporan (Kinerja_Tanda Tangan) - ini sudah siap untuk integrasi dengan Jenkins, yang dikembangkan oleh orang-orang dari T-Systems Multimedia Solutions. Setiap acara peluncuran pengujian berisi informasi tentang layanan, nomor build, dan waktu pengujian. Plugin mengumpulkan nilai kinerja pada waktu build, mengevaluasinya, dan membandingkan hasilnya dengan build sebelumnya dan persyaratan non-fungsional.
Peristiwa dalam sistem pemantauan tentang dimulainya pemeriksaan kualitas build.
Setelah pengujian selesai, semua metrik untuk menilai kualitas perangkat lunak ditransfer kembali ke sistem integrasi berkelanjutan, misalnya Jenkins, yang menghasilkan laporan tentang hasilnya.
Hasil statistik rakitan di server CI/CD.
Untuk setiap build individu, kami melihat statistik untuk setiap metrik yang kami tetapkan sepanjang pengujian. Kami juga melihat apakah ada pelanggaran pada nilai ambang batas tertentu (peringatan dan ambang batas yang parah). Berdasarkan metrik agregat, keseluruhan build ditandai sebagai stabil, tidak stabil, atau gagal. Selain itu, untuk kenyamanan, Anda dapat menambahkan indikator ke laporan yang membandingkan build saat ini dengan build sebelumnya.
Lihat statistik terperinci tentang rakitan di server CI/CD.
Perbandingan terperinci dari dua majelis
Jika perlu, Anda dapat membuka antarmuka Dynatrace dan di sana Anda dapat melihat statistik untuk setiap bangunan Anda secara lebih rinci dan membandingkannya satu sama lain.
Perbandingan statistik build di Dynatrace.
Temuan
Hasilnya, kami mendapatkan layanan “pemantauan sebagai layanan”, yang diotomatisasi dalam jalur integrasi berkelanjutan. Pengembang atau penguji hanya perlu menentukan daftar metrik dalam file JSON, dan semuanya terjadi secara otomatis. Kami menerima kontrol kualitas rilis yang transparan: semua pemberitahuan tentang kinerja, konsumsi sumber daya, atau regresi arsitektur.
Tugas 2. Otomatisasi pengendalian kualitas perangkat lunak di lingkungan produksi
Jadi, kami telah memecahkan masalah bagaimana mengotomatiskan proses pemantauan pada tahap pengujian di Pipeline. Dengan cara ini kami meminimalkan persentase rakitan berkualitas rendah yang mencapai lingkungan produksi.
Namun apa yang harus dilakukan jika perangkat lunak yang buruk akhirnya dijual, atau ada yang rusak. Untuk utopia, kami menginginkan mekanisme yang secara otomatis mendeteksi masalah dan, jika mungkin, sistem itu sendiri yang memulihkan fungsinya, setidaknya di malam hari.
Untuk melakukan hal ini, kita perlu, dengan analogi dengan bagian sebelumnya, menyediakan pemeriksaan kualitas perangkat lunak otomatis di lingkungan produksi dan mendasarkannya pada skenario untuk penyembuhan mandiri sistem.
Koreksi otomatis sebagai kode
Sebagian besar perusahaan telah memiliki basis pengetahuan yang terakumulasi tentang berbagai jenis masalah umum dan daftar tindakan untuk memperbaikinya, misalnya memulai ulang proses, membersihkan sumber daya, mengembalikan versi, memulihkan perubahan konfigurasi yang tidak valid, menambah atau mengurangi jumlah komponen dalam cluster, mengganti garis biru atau hijau dan lain-lain.
Meskipun kasus penggunaan ini telah diketahui selama bertahun-tahun oleh banyak tim yang saya ajak bicara, hanya sedikit yang memikirkan atau berinvestasi dalam mengotomatisasinya.
Jika dipikir-pikir, tidak ada yang terlalu rumit dalam mengimplementasikan proses untuk kinerja aplikasi yang memulihkan diri; Anda perlu menyajikan skenario kerja administrator Anda yang sudah diketahui dalam bentuk skrip kode (konsep "perbaikan otomatis sebagai kode") , yang Anda tulis sebelumnya untuk setiap kasus tertentu. Skrip perbaikan otomatis harus ditujukan untuk menghilangkan akar penyebab masalah. Anda sendiri yang menentukan tindakan yang tepat untuk menyikapi suatu kejadian.
Metrik apa pun dari sistem pemantauan Anda dapat bertindak sebagai pemicu untuk meluncurkan skrip, yang utama adalah metrik ini secara akurat menentukan bahwa semuanya buruk, karena Anda tidak ingin mendapatkan hasil positif palsu di lingkungan yang produktif.
Anda dapat menggunakan sistem atau rangkaian sistem apa pun: Prometheus, ELK Stack, Zabbix, dll. Namun saya akan memberikan beberapa contoh berdasarkan solusi APM (Dynatrace akan menjadi contohnya lagi) yang juga akan membantu membuat hidup Anda lebih mudah.
Pertama, segala sesuatu yang berhubungan dengan kinerja dalam hal pengoperasian aplikasi. Solusinya menyediakan ratusan metrik di berbagai tingkat yang dapat Anda gunakan sebagai pemicu:
- tingkat pengguna (browser, aplikasi seluler, perangkat IoT, perilaku pengguna, konversi, dll.);
- tingkat layanan dan operasi (kinerja, ketersediaan, kesalahan, dll.);
- tingkat infrastruktur aplikasi (metrik OS host, JMX, MQ, server web, dll.);
- tingkat platform (virtualisasi, cloud, container, dll.).
Tingkat pemantauan di Dynatrace.
Kedua, seperti yang saya katakan sebelumnya, Dynatrace memiliki API terbuka, yang membuatnya sangat mudah untuk diintegrasikan dengan berbagai sistem pihak ketiga. Misalnya, mengirimkan pemberitahuan ke sistem otomasi ketika parameter kontrol terlampaui.
Di bawah ini adalah contoh interaksi dengan Ansible.
Di bawah ini saya akan memberikan beberapa contoh otomatisasi seperti apa yang bisa dilakukan. Ini hanyalah sebagian dari kasus; daftarnya di lingkungan Anda hanya dapat dibatasi oleh imajinasi Anda dan kemampuan alat pemantauan Anda.
1. Penerapan yang buruk – pengembalian versi
Meskipun kami menguji semuanya dengan sangat baik di lingkungan pengujian, masih ada kemungkinan rilis baru dapat mematikan aplikasi Anda di lingkungan produksi. Faktor manusia yang sama belum dibatalkan.
Pada gambar berikut kita melihat adanya lonjakan tajam dalam waktu pelaksanaan operasi pada layanan. Awal lompatan ini bertepatan dengan waktu penerapan aplikasi. Kami mengirimkan semua informasi ini sebagai peristiwa ke sistem otomasi. Jika kinerja layanan tidak kembali normal setelah waktu yang kita tetapkan, maka skrip secara otomatis dipanggil untuk mengembalikan versi ke versi lama.
Penurunan kinerja operasi setelah penerapan.
2. Pemuatan sumber daya 100% - tambahkan node ke perutean
Dalam contoh berikut, sistem pemantauan menentukan bahwa salah satu komponen mengalami beban CPU 100%.
Beban CPU 100%
Ada beberapa skenario berbeda yang mungkin terjadi untuk peristiwa ini. Misalnya, sistem pemantauan juga memeriksa apakah kekurangan sumber daya dikaitkan dengan peningkatan beban layanan. Jika demikian, maka skrip dijalankan yang secara otomatis menambahkan node ke perutean, sehingga memulihkan fungsionalitas sistem secara keseluruhan.
Penskalaan setelah insiden
3. Kurangnya ruang pada hard drive - pembersihan disk
Saya rasa banyak orang telah mengotomatiskan proses ini. Menggunakan APM, Anda juga dapat memantau ruang kosong pada subsistem disk. Jika tidak ada ruang atau disk berjalan lambat, kami memanggil skrip untuk membersihkannya atau menambah ruang.
Pemuatan disk 100%
4. Aktivitas pengguna rendah atau konversi rendah - beralih antara cabang biru dan hijau
Saya sering melihat pelanggan menggunakan dua loop (penerapan biru-hijau) untuk aplikasi di lingkungan produksi. Hal ini memungkinkan Anda dengan cepat beralih antar cabang saat mengirimkan rilis baru. Seringkali, setelah penerapan, perubahan dramatis dapat terjadi yang tidak langsung terlihat. Dalam hal ini, penurunan kinerja dan ketersediaan mungkin tidak terlihat. Untuk merespons perubahan tersebut dengan cepat, lebih baik menggunakan berbagai metrik yang mencerminkan perilaku pengguna (jumlah sesi dan tindakan pengguna, konversi, rasio pentalan). Gambar berikut menunjukkan contoh di mana, ketika tingkat konversi turun, terjadi peralihan antar cabang perangkat lunak.
Tingkat konversi turun setelah beralih antar cabang perangkat lunak.
Mekanisme untuk deteksi masalah otomatis
Terakhir, saya akan memberikan satu contoh lagi mengapa saya paling menyukai Dynatrace.
Di bagian cerita saya tentang mengotomatiskan pemeriksaan kualitas rakitan di lingkungan pengujian, kami menentukan semua nilai ambang batas secara manual. Hal ini normal untuk lingkungan pengujian; penguji sendiri yang menentukan indikator sebelum setiap pengujian tergantung pada beban. Dalam lingkungan produksi, diharapkan masalah terdeteksi secara otomatis, dengan mempertimbangkan berbagai mekanisme dasar.
Dynatrace memiliki alat kecerdasan buatan bawaan yang menarik yang, berdasarkan mekanisme untuk menentukan metrik anomali (baselining) dan membangun peta interaksi antara semua komponen, membandingkan dan mengkorelasikan peristiwa satu sama lain, menentukan anomali dalam pengoperasian layanan Anda dan memberikan rincian informasi tentang setiap masalah dan akar permasalahan.
Dengan menganalisis ketergantungan antar komponen secara otomatis, Dynatrace menentukan tidak hanya apakah layanan yang bermasalah merupakan penyebab utama, namun juga ketergantungannya pada layanan lain. Pada contoh di bawah, Dynatrace secara otomatis memantau dan mengevaluasi kesehatan setiap layanan dalam eksekusi transaksi, mengidentifikasi layanan Golang sebagai penyebab utama.
Contoh penentuan akar penyebab kegagalan.
Gambar berikut menunjukkan proses pemantauan masalah pada aplikasi Anda sejak awal kejadian.
Visualisasi masalah yang muncul dengan tampilan semua komponen dan kejadian di dalamnya
Sistem monitoring mengumpulkan kronologi kejadian secara lengkap terkait permasalahan yang muncul. Pada jendela di bawah timeline kita melihat semua peristiwa penting pada masing-masing komponen. Berdasarkan kejadian tersebut, Anda dapat mengatur prosedur koreksi otomatis dalam bentuk skrip kode.
Selain itu, saya menyarankan Anda untuk mengintegrasikan sistem pemantauan dengan Service Desk atau pelacak bug. Ketika masalah terjadi, pengembang dengan cepat menerima informasi lengkap untuk menganalisisnya pada tingkat kode di lingkungan produksi.
Kesimpulan
Hasilnya, kami mendapatkan pipeline CI/CD dengan pemeriksaan kualitas perangkat lunak otomatis bawaan di Pipeline. Kami meminimalkan jumlah build berkualitas rendah, meningkatkan keandalan sistem secara keseluruhan, dan jika sistem kami masih gagal, kami meluncurkan mekanisme untuk memulihkannya.
Upaya untuk mengotomatisasi pemantauan kualitas perangkat lunak tentu saja layak dilakukan; proses ini tidak selalu cepat, namun seiring berjalannya waktu akan membuahkan hasil. Saya menyarankan bahwa setelah menyelesaikan insiden baru di lingkungan produksi, Anda segera memikirkan monitor mana yang akan ditambahkan untuk pemeriksaan di lingkungan pengujian guna menghindari build yang buruk masuk ke produksi, dan juga membuat skrip untuk memperbaiki masalah ini secara otomatis.
Saya harap contoh saya akan membantu usaha Anda. Saya juga tertarik melihat contoh metrik yang digunakan untuk menerapkan sistem penyembuhan diri.
Sumber: www.habr.com