Diketahui, kompetensi CTO baru diuji kedua kalinya dalam menjalankan peran tersebut. Karena bekerja di sebuah perusahaan selama beberapa tahun, berkembang bersamanya dan, dalam konteks budaya yang sama, secara bertahap menerima lebih banyak tanggung jawab adalah satu hal. Dan merupakan hal yang berbeda untuk langsung menduduki posisi direktur teknis di sebuah perusahaan dengan warisan warisan dan banyak masalah yang terselubung dengan rapi.

Dalam hal ini, pengalaman Leon Fire, yang dia bagikan lebih lanjut DevOpsConf, tidak bisa dibilang unik, tapi ditambah dengan pengalamannya dan banyaknya peran berbeda yang berhasil dia coba selama 20 tahun, ini sangat berguna. Di bawah potongan tersebut adalah kronologi kejadian selama 90 hari dan segudang cerita yang asyik untuk ditertawakan jika terjadi pada orang lain, namun tidak begitu asyik untuk dihadapi secara langsung.

Leon berbicara bahasa Rusia dengan sangat penuh warna, jadi jika Anda punya waktu 35-40 menit, saya sarankan menonton videonya. Versi teks untuk menghemat waktu di bawah.

Versi pertama laporan ini merupakan deskripsi yang terstruktur dengan baik tentang cara bekerja dengan orang-orang dan proses, serta berisi rekomendasi-rekomendasi yang bermanfaat. Namun ia tidak menyampaikan semua kejutan yang ditemui sepanjang perjalanan. Oleh karena itu, saya mengubah format dan menyajikan masalah yang muncul di hadapan saya seperti jack-in-the-box di perusahaan baru, dan metode penyelesaiannya dalam urutan kronologis.

Satu bulan sebelumnya

Seperti banyak cerita bagus lainnya, cerita ini dimulai dengan alkohol. Kami sedang duduk bersama teman-teman di sebuah bar, dan seperti yang diharapkan di antara para spesialis TI, semua orang menangis tentang masalah mereka. Salah satu dari mereka baru saja berganti pekerjaan dan membicarakan masalahnya dengan teknologi, dengan manusia, dan dengan tim. Semakin saya mendengarkan, semakin saya menyadari bahwa dia sebaiknya mempekerjakan saya saja, karena ini adalah jenis masalah yang telah saya pecahkan selama 15 tahun terakhir. Saya bilang begitu padanya, dan keesokan harinya kami bertemu di lingkungan kerja. Perusahaan itu bernama Strategi Pengajaran.

Strategi Pengajaran adalah pemimpin pasar dalam kurikulum untuk anak-anak yang masih sangat kecil sejak lahir hingga usia tiga tahun. Perusahaan “kertas” tradisional sudah berusia 40 tahun, dan platform versi SaaS digital berusia 10 tahun.Relatif baru-baru ini, proses adaptasi teknologi digital dengan standar perusahaan dimulai. Versi “baru” diluncurkan pada tahun 2017 dan hampir seperti versi lama, hanya saja kinerjanya lebih buruk.

Yang paling menarik adalah trafik perusahaan ini sangat mudah ditebak - dari hari ke hari, dari tahun ke tahun, Anda bisa dengan jelas memprediksi berapa banyak orang yang akan datang dan kapan. Misalnya, antara jam 13 dan 15 siang, semua anak di taman kanak-kanak pergi tidur dan guru mulai memasukkan informasi. Dan ini terjadi setiap hari, kecuali akhir pekan, karena hampir tidak ada orang yang bekerja di akhir pekan.

Melihat ke depan sedikit, saya perhatikan bahwa saya memulai pekerjaan saya selama periode lalu lintas tahunan tertinggi, yang menarik karena berbagai alasan.

Platform ini, yang tampaknya baru berusia 2 tahun, memiliki tumpukan yang aneh: ColdFusion & SQL Server dari tahun 2008. ColdFusion, jika Anda belum mengetahuinya, dan kemungkinan besar Anda belum mengetahuinya, adalah PHP perusahaan yang keluar pada pertengahan tahun 90an, dan sejak itu saya belum pernah mendengarnya lagi. Ada juga: Ruby, MySQL, PostgreSQL, Java, Go, Python. Tapi monolit utama berjalan di ColdFusion dan SQL Server.

Masalah

Semakin banyak saya berbincang dengan karyawan perusahaan mengenai pekerjaan dan permasalahan apa saja yang dihadapi, semakin saya menyadari bahwa permasalahan tersebut tidak hanya bersifat teknis saja. Oke, teknologinya sudah tua - dan mereka tidak mengerjakannya, tetapi ada masalah dengan tim dan prosesnya, dan perusahaan mulai memahami hal ini.

Secara tradisional, teknisi mereka duduk di sudut dan melakukan suatu pekerjaan. Namun kini semakin banyak bisnis yang mulai beralih ke versi digital. Oleh karena itu, pada tahun terakhir sebelum saya mulai bekerja, muncullah orang-orang baru di perusahaan: dewan direksi, CTO, CPO dan direktur QA. Artinya, perusahaan mulai berinvestasi di sektor teknologi.

Jejak warisan besar tidak hanya ada di sistem. Perusahaan ini memiliki proses yang diwariskan, orang-orang yang diwariskan, dan budaya yang diwariskan. Semua ini harus diubah. Saya pikir itu pasti tidak membosankan, dan memutuskan untuk mencobanya.

Dua hari sebelumnya

Dua hari sebelum memulai pekerjaan baru, saya tiba di kantor, mengisi dokumen terakhir, bertemu dengan tim, dan menemukan bahwa tim sedang mengalami masalah pada saat itu. Rata-rata waktu pemuatan halaman melonjak menjadi 4 detik, yakni 2 kali lipat.

Dilihat dari grafiknya, jelas ada sesuatu yang terjadi, dan tidak jelas apa. Ternyata masalahnya adalah latensi jaringan di pusat data: latensi 5 ms di pusat data berubah menjadi 2 detik untuk pengguna. Saya tidak tahu mengapa ini terjadi, tetapi bagaimanapun juga diketahui bahwa masalahnya ada di pusat data.

Hari pertama

Dua hari berlalu dan pada hari pertama saya bekerja, saya menemukan bahwa masalahnya belum hilang.

Selama dua hari, halaman pengguna dimuat rata-rata dalam 4 detik. Saya bertanya apakah mereka menemukan apa masalahnya.

- Ya, kami membuka tiket.
- DAN?
- Yah, mereka belum menjawab kita.

Kemudian saya menyadari bahwa semua yang telah diberitahukan kepada saya sebelumnya hanyalah puncak kecil dari gunung es yang harus saya lawan.

Ada kutipan bagus yang sangat cocok dengan hal ini:

“Terkadang untuk mengubah teknologi Anda harus mengubah organisasi.”

Namun karena saya mulai bekerja pada waktu tersibuk dalam setahun, saya harus mempertimbangkan kedua opsi untuk menyelesaikan masalah: cepat dan jangka panjang. Dan mulailah dengan apa yang penting saat ini.

Hari ketiga

Jadi, pemuatan berlangsung 4 detik, dan dari 13 hingga 15 puncak terbesar.

Pada hari ketiga selama periode waktu ini, kecepatan download terlihat seperti ini:

Dari sudut pandang saya, tidak ada yang berhasil sama sekali. Dari sudut pandang orang lain, ini berjalan sedikit lebih lambat dari biasanya. Namun hal itu tidak terjadi begitu saja—ini adalah masalah yang serius.

Saya mencoba meyakinkan tim, dan mereka menjawab bahwa mereka hanya membutuhkan lebih banyak server. Tentu saja ini merupakan solusi terhadap masalah tersebut, namun tidak selalu merupakan satu-satunya solusi yang paling efektif. Saya bertanya mengapa servernya tidak cukup, berapa volume lalu lintasnya. Saya mengekstrapolasi data dan menemukan bahwa kami memiliki sekitar 150 permintaan per detik, yang pada prinsipnya berada dalam batas wajar.

Namun kita tidak boleh lupa bahwa sebelum Anda mendapatkan jawaban yang benar, Anda perlu mengajukan pertanyaan yang tepat. Pertanyaan saya berikutnya adalah: berapa banyak server frontend yang kita miliki? Jawabannya “sedikit membingungkan saya” - kami memiliki 17 server frontend!

— Aku malu bertanya, tapi 150 dibagi 17 hasilnya 8? Apakah Anda mengatakan bahwa setiap server mengizinkan 8 permintaan per detik, dan jika besok ada 160 permintaan per detik, kami memerlukan 2 server lagi?

Tentu saja kami tidak memerlukan server tambahan. Solusinya ada pada kode itu sendiri, dan di permukaan:

var currentClass = classes.getCurrentClass();
return currentClass;

Ada sebuah fungsi getCurrentClass(), karena semua yang ada di situs berfungsi dalam konteks kelas - itu benar. Dan untuk fungsi yang satu ini di setiap halamannya ada 200+ permintaan.

Solusinya sangat sederhana, Anda bahkan tidak perlu menulis ulang apa pun: cukup jangan meminta informasi yang sama lagi.

if ( !isDefined("REQUEST.currentClass") ) {
    var classes = new api.private.classes.base();
   REQUEST.currentClass = classes.getCurrentClass();
}
return REQUEST.currentClass;

Saya sangat senang karena saya memutuskan bahwa pada hari ketiga saya telah menemukan masalah utama. Meskipun saya naif, ini hanyalah salah satu dari banyak masalah.

Namun penyelesaian masalah pertama ini menurunkan grafiknya jauh lebih rendah.

Pada saat yang sama, kami melakukan pengoptimalan lainnya. Ada banyak hal yang bisa diperbaiki. Misalnya, pada hari ketiga yang sama saya menemukan bahwa ada cache di sistem (awalnya saya mengira semua permintaan datang langsung dari database). Ketika saya memikirkan cache, saya memikirkan Redis atau Memcached standar. Tapi saya satu-satunya yang berpikir begitu, karena sistem itu menggunakan MongoDB dan SQL Server untuk caching - sistem yang sama yang baru saja membaca datanya.

Hari kesepuluh

Minggu pertama saya menangani masalah yang perlu diselesaikan saat ini. Di minggu kedua, saya datang ke stand-up untuk pertama kalinya untuk berkomunikasi dengan tim, untuk melihat apa yang terjadi dan bagaimana keseluruhan prosesnya.

Sesuatu yang menarik ditemukan kembali. Tim tersebut terdiri dari: 18 pengembang; 8 penguji; 3 manajer; 2 arsitek. Dan mereka semua berpartisipasi dalam ritual umum, yaitu lebih dari 30 orang datang ke stand-up setiap pagi dan menceritakan apa yang mereka lakukan. Yang jelas pertemuan itu tidak memakan waktu 5 atau 15 menit. Tidak ada yang mendengarkan siapa pun karena setiap orang bekerja pada sistem yang berbeda. Dalam bentuk ini, 2-3 tiket per jam untuk sesi perawatan sudah merupakan hasil yang bagus.

Hal pertama yang kami lakukan adalah membagi tim menjadi beberapa lini produk. Untuk bagian dan sistem yang berbeda, kami mengalokasikan tim terpisah, yang mencakup pengembang, penguji, manajer produk, dan analis bisnis.

Hasilnya, kami mendapatkan:

Mengurangi stand-up dan demonstrasi.
Pengetahuan subjek tentang produk.
Rasa memiliki. Ketika orang terbiasa mengutak-atik sistem sepanjang waktu, mereka tahu bahwa kemungkinan besar orang lain harus mengatasi bug mereka, tetapi bukan diri mereka sendiri.
Kolaborasi antar kelompok. Tak perlu dikatakan lagi, QA tidak banyak berkomunikasi dengan pemrogram sebelumnya, produk melakukan tugasnya sendiri, dll. Sekarang mereka mempunyai tanggung jawab yang sama.

Kami terutama berfokus pada efisiensi, produktivitas, dan kualitas - ini adalah masalah yang kami coba selesaikan dengan transformasi tim.

Hari kesebelas

Dalam proses mengubah struktur tim, saya menemukan cara berhitung CeritaPoin. 1 SP sama dengan satu hari, dan setiap tiket berisi SP untuk pengembangan dan QA, yaitu minimal 2 SP.

Bagaimana saya mengetahui hal ini?

Kami menemukan bug: di salah satu laporan, yang memasukkan tanggal mulai dan akhir periode yang memerlukan laporan, hari terakhir tidak diperhitungkan. Artinya, di suatu tempat dalam permintaan tidak ada <=, tetapi hanya <. Saya diberitahu bahwa ini adalah tiga Poin Cerita 3 hari.

Setelah ini kita:

Sistem penilaian Story Points telah direvisi. Sekarang perbaikan untuk bug kecil yang dapat dengan cepat melewati sistem menjangkau pengguna lebih cepat.
Kami mulai menggabungkan tiket terkait untuk pengembangan dan pengujian. Sebelumnya, setiap tiket, setiap bug adalah ekosistem tertutup, tidak terikat dengan hal lain. Mengubah tiga tombol pada satu halaman bisa berarti tiga tiket berbeda dengan tiga proses QA berbeda, bukan satu pengujian otomatis per halaman.
Kami mulai bekerja sama dengan pengembang dalam pendekatan memperkirakan biaya tenaga kerja. Tiga hari untuk mengganti satu tombol tidaklah lucu.

Hari kedua puluh

Di pertengahan bulan pertama, situasinya sedikit stabil, saya mengetahui apa yang pada dasarnya terjadi, dan sudah mulai melihat ke masa depan dan memikirkan solusi jangka panjang.

Tujuan jangka panjang:

Platform yang dikelola. Ratusan permintaan di setiap halaman tidaklah serius.
Tren yang dapat diprediksi. Ada puncak lalu lintas berkala yang pada pandangan pertama tidak berkorelasi dengan metrik lainnya - kami perlu memahami mengapa hal ini terjadi dan belajar memprediksi.
Perluasan platform. Bisnis terus berkembang, semakin banyak pengguna yang datang, dan lalu lintas meningkat.

Dahulu sering dikatakan: “Mari kita tulis ulang semuanya dalam [bahasa/kerangka], semuanya akan bekerja lebih baik!”

Dalam kebanyakan kasus, ini tidak berhasil, ada baiknya jika penulisan ulang berhasil. Oleh karena itu, kami perlu membuat peta jalan – strategi spesifik yang menggambarkan langkah demi langkah bagaimana tujuan bisnis akan dicapai (apa yang akan kami lakukan dan mengapa), yang mana:

mencerminkan misi dan tujuan proyek;
memprioritaskan tujuan utama;
berisi jadwal untuk mencapainya.

Sebelumnya, tidak ada seorang pun yang berbicara dengan tim tentang tujuan perubahan yang dilakukan. Hal ini memerlukan metrik keberhasilan yang tepat. Untuk pertama kalinya dalam sejarah perusahaan, kami menetapkan KPI untuk kelompok teknis, dan indikator-indikator ini dikaitkan dengan organisasi.

Artinya, KPI organisasi didukung oleh tim, dan KPI tim didukung oleh KPI individu. Sebaliknya, jika KPI teknologi tidak sesuai dengan KPI organisasi, maka semua orang akan menutupi dirinya sendiri.

Misalnya, salah satu KPI organisasi adalah meningkatkan pangsa pasar melalui produk baru.

Bagaimana Anda dapat mendukung tujuan memiliki lebih banyak produk baru?

Pertama, kami ingin menghabiskan lebih banyak waktu untuk mengembangkan produk baru daripada memperbaiki produk cacat. Ini adalah solusi logis yang mudah diukur.
Kedua, kami ingin mendukung peningkatan volume transaksi, karena semakin besar pangsa pasar, semakin banyak pengguna dan semakin banyak lalu lintas.

Kemudian KPI individu yang dapat dijalankan dalam grup, misalnya, akan berada di tempat asal cacat utama. Jika Anda fokus secara khusus pada bagian ini, Anda dapat memastikan bahwa cacatnya jauh lebih sedikit, dan waktu untuk mengembangkan produk baru dan lagi untuk mendukung KPI organisasi akan meningkat.

Oleh karena itu, setiap keputusan, termasuk penulisan ulang kode, harus mendukung tujuan spesifik yang telah ditetapkan perusahaan untuk kita (pertumbuhan organisasi, fitur baru, rekrutmen).

Dalam proses ini, ada hal menarik yang terungkap, yang menjadi berita tidak hanya bagi para teknisi, tetapi secara umum di perusahaan: semua tiket harus fokus pada setidaknya satu KPI. Artinya, jika suatu produk mengatakan ingin membuat fitur baru, pertanyaan pertama yang harus ditanyakan: “KPI apa yang didukung fitur ini?” Jika tidak, maka maaf - sepertinya fitur yang tidak perlu.

Hari ketiga puluh

Di akhir bulan, saya menemukan nuansa lain: tidak ada seorang pun di tim Operasi saya yang pernah melihat kontrak yang kami buat dengan klien. Anda mungkin bertanya mengapa Anda perlu melihat kontak.

Pertama, karena SLA ditentukan dalam kontrak.
Kedua, semua SLA berbeda. Setiap klien datang dengan persyaratannya sendiri, dan departemen penjualan menandatanganinya tanpa melihat.

Nuansa menarik lainnya adalah kontrak dengan salah satu klien terbesar menyatakan bahwa semua versi perangkat lunak yang didukung oleh platform harus n-1, yaitu bukan versi terbaru, melainkan versi kedua dari belakang.

Jelas seberapa jauh kita dari n-1 jika platform tersebut didasarkan pada ColdFusion dan SQL Server 2008, yang tidak lagi didukung sama sekali pada bulan Juli.

Hari ke empat puluh lima

Sekitar pertengahan bulan kedua saya punya cukup waktu untuk duduk dan melakukan nilaialiranpemetaan sepenuhnya untuk keseluruhan proses. Ini adalah langkah-langkah penting yang perlu diambil, mulai dari pembuatan produk hingga pengirimannya ke konsumen, dan langkah-langkah tersebut perlu dijelaskan sedetail mungkin.

Anda memecah proses menjadi bagian-bagian kecil dan melihat apa yang memakan terlalu banyak waktu, apa yang dapat dioptimalkan, ditingkatkan, dll. Misalnya berapa lama permintaan produk melalui grooming, kapan sampai pada tiket yang bisa diambil developer, QA, dan sebagainya. Jadi, Anda melihat setiap langkah secara mendetail dan memikirkan apa yang dapat dioptimalkan.

Ketika saya melakukan ini, ada dua hal yang menarik perhatian saya:

tingginya persentase tiket yang dikembalikan dari QA ke pengembang;
peninjauan permintaan tarik memakan waktu terlalu lama.

Masalahnya adalah kesimpulannya seperti ini: Sepertinya memakan banyak waktu, tapi kami tidak yakin berapa lama.

"Anda tidak dapat memperbaiki apa yang tidak dapat Anda ukur."

Bagaimana menjelaskan betapa seriusnya masalah ini? Apakah itu membuang-buang waktu berhari-hari atau berjam-jam?

Untuk mengukurnya, kami menambahkan beberapa langkah ke proses Jira: “siap untuk pengembangan” dan “siap untuk QA” untuk mengukur berapa lama setiap tiket menunggu dan berapa kali tiket kembali ke langkah tertentu.

Kami juga menambahkan "sedang ditinjau" untuk mengetahui berapa rata-rata tiket yang ditinjau, dan dari sini Anda dapat mulai menari. Kami memiliki metrik sistem, sekarang kami menambahkan metrik baru dan mulai mengukur:

Efisiensi proses: kinerja dan direncanakan/disampaikan.
Kualitas proses: jumlah cacat, cacat dari QA.

Sangat membantu untuk memahami apa yang berjalan dengan baik dan apa yang tidak berjalan dengan baik.

Hari kelima puluh

Ini semua tentu saja bagus dan menarik, namun menjelang akhir bulan kedua terjadi sesuatu yang pada prinsipnya sudah bisa ditebak, meski saya tidak menyangka sebesar itu. Orang-orang mulai keluar karena manajemen puncak telah berganti. Orang-orang baru masuk ke dalam manajemen dan mulai mengubah segalanya, dan orang-orang lama berhenti. Dan biasanya dalam sebuah perusahaan yang berumur beberapa tahun, semua orang berteman dan semua orang saling mengenal.

Hal ini sudah diduga, namun skala PHK tidak terduga. Misalnya, dalam satu minggu, dua pimpinan tim secara bersamaan mengajukan pengunduran diri atas kemauan mereka sendiri. Oleh karena itu, saya tidak hanya harus melupakan masalah lain, tetapi juga fokus menciptakan sebuah tim. Ini adalah masalah yang panjang dan sulit untuk diselesaikan, namun harus diselesaikan karena saya ingin menyelamatkan orang-orang yang masih tersisa (atau sebagian besar dari mereka). Penting untuk bereaksi terhadap kenyataan bahwa orang-orang pergi untuk menjaga moral dalam tim.

Secara teori, ini bagus: masuklah orang baru yang memiliki kekuasaan penuh, yang dapat mengevaluasi keterampilan tim dan mengganti personel. Faktanya, Anda tidak bisa begitu saja mendatangkan orang baru karena berbagai alasan. Keseimbangan selalu dibutuhkan.

Lama dan baru. Kita perlu mempertahankan orang-orang tua yang dapat mengubah dan mendukung misi ini. Namun di saat yang sama, kami perlu mendatangkan pemain baru, kami akan membicarakannya nanti.
Pengalaman. Saya banyak berbicara dengan junior baik yang bersemangat dan ingin bekerja bersama kami. Tapi saya tidak bisa menerima mereka karena tidak ada cukup senior untuk mendukung junior dan bertindak sebagai mentor bagi mereka. Pertama-tama perlu merekrut para petinggi dan baru kemudian para pemuda.
Wortel dan tongkat.

Saya tidak mempunyai jawaban yang baik terhadap pertanyaan mengenai keseimbangan yang tepat, bagaimana mempertahankannya, berapa banyak orang yang harus dipertahankan, dan berapa banyak yang harus didorong. Ini adalah proses yang murni individual.

Hari ke lima puluh satu

Saya mulai mencermati tim untuk memahami siapa yang saya miliki, dan sekali lagi saya ingat:

“Sebagian besar masalah adalah masalah manusia.”

Saya menemukan bahwa tim - baik Dev maupun Ops - memiliki tiga masalah besar:

Kepuasan dengan keadaan saat ini.
Kurangnya tanggung jawab - karena belum pernah ada orang yang membawa hasil karya para pelakunya untuk mempengaruhi bisnis.
Takut akan perubahan.

Perubahan selalu membawa Anda keluar dari zona nyaman Anda, dan semakin muda usia Anda, semakin mereka tidak menyukai perubahan karena mereka tidak memahami alasannya dan tidak memahami caranya. Jawaban paling umum yang pernah saya dengar adalah, "Kami belum pernah melakukan hal itu." Selain itu, hal ini mencapai titik yang benar-benar absurd - perubahan sekecil apa pun tidak akan terjadi tanpa ada yang marah. Dan tidak peduli seberapa besar perubahan tersebut mempengaruhi pekerjaan mereka, orang-orang berkata: “Tidak, kenapa? Ini tidak akan berhasil."

Tapi Anda tidak bisa menjadi lebih baik tanpa mengubah apa pun.

Saya melakukan percakapan yang benar-benar tidak masuk akal dengan seorang karyawan, saya memberi tahu dia ide saya untuk pengoptimalan, dan dia memberi tahu saya:
- Oh, kamu tidak melihat apa yang kita alami tahun lalu!
- Terus?
“Sekarang jauh lebih baik dari sebelumnya.”
- Jadi, tidak ada yang lebih baik lagi?
- Untuk apa?

Pertanyaan bagus - mengapa? Seolah-olah sekarang lebih baik dari sebelumnya, maka semuanya sudah cukup baik. Hal ini menyebabkan kurangnya tanggung jawab, yang pada prinsipnya merupakan hal yang normal. Seperti yang saya katakan, kelompok teknis sedikit berada di pinggir lapangan. Perusahaan percaya bahwa mereka seharusnya ada, tapi tidak ada yang pernah menetapkan standar. Dukungan teknis tidak pernah melihat SLA, jadi cukup “dapat diterima” untuk grup (dan ini yang paling mengejutkan saya):

pemuatan 12 detik;
Waktu henti 5-10 menit setiap rilis;
Pemecahan masalah kritis memerlukan waktu berhari-hari dan berminggu-minggu;
kurangnya petugas jaga 24x7/on-call.

Tidak ada seorang pun yang pernah bertanya mengapa kita tidak melakukannya dengan lebih baik, dan tidak ada seorang pun yang pernah menyadari bahwa tidak harus seperti ini.

Sebagai bonus, ada satu masalah lagi: kurang pengalaman. Para senior pergi, dan tim muda yang tersisa tumbuh di bawah rezim sebelumnya dan diracuni olehnya.

Selain itu, masyarakat juga takut gagal dan terlihat tidak kompeten. Hal ini terungkap dalam kenyataan bahwa, pertama, mereka dalam keadaan apa pun tidak meminta bantuan. Berapa kali kita berbicara sebagai kelompok dan secara individu, dan saya berkata, “Ajukan pertanyaan jika Anda tidak tahu bagaimana melakukan sesuatu.” Saya percaya diri dan tahu bahwa saya bisa menyelesaikan masalah apa pun, tapi itu butuh waktu. Oleh karena itu, jika saya dapat bertanya kepada seseorang yang mengetahui cara menyelesaikannya dalam 10 menit, saya akan bertanya. Semakin sedikit pengalaman yang Anda miliki, semakin takut Anda untuk bertanya karena Anda merasa dianggap tidak kompeten.

Ketakutan untuk mengajukan pertanyaan ini diwujudkan dalam cara yang menarik. Misalnya, Anda bertanya: “Bagaimana kabar Anda dengan tugas ini?” - “Tinggal beberapa jam lagi, aku sudah menyelesaikannya.” Keesokan harinya Anda bertanya lagi, Anda mendapat jawaban bahwa semuanya baik-baik saja, tetapi ada satu masalah, pasti akan siap pada akhir hari. Hari lain berlalu, dan sampai Anda terjepit di dinding dan dipaksa untuk berbicara dengan seseorang, hal ini terus berlanjut. Seseorang ingin memecahkan masalahnya sendiri, ia percaya bahwa jika ia tidak menyelesaikannya sendiri, maka itu akan menjadi kegagalan besar.

Itu sebabnya para pengembang menggelembungkan perkiraan tersebut. Anekdot yang sama, ketika mereka mendiskusikan tugas tertentu, mereka memberi saya gambaran yang membuat saya sangat terkejut. Yang saya diberitahu bahwa dalam perkiraan pengembang, pengembang memasukkan waktu pengembalian tiket dari QA, karena mereka akan menemukan kesalahan di sana, dan waktu yang dibutuhkan PR, dan waktu sementara orang yang harus meninjau itu akan sibuk - yaitu, segalanya, apa pun yang mungkin.

Kedua, orang yang takut tampil tidak kompeten menganalisis secara berlebihan. Saat Anda mengatakan apa sebenarnya yang perlu dilakukan, hal itu dimulai: “Tidak, bagaimana jika kita memikirkannya di sini?” Dalam hal ini, perusahaan kami tidaklah unik; ini adalah masalah standar bagi kaum muda.

Sebagai tanggapan, saya memperkenalkan praktik berikut:

Aturan 30 menit. Jika Anda tidak dapat menyelesaikan masalah dalam waktu setengah jam, mintalah bantuan seseorang. Cara ini berhasil dengan tingkat keberhasilan yang berbeda-beda, karena masyarakat masih belum bertanya, namun setidaknya prosesnya sudah dimulai.
Hilangkan semuanya kecuali intinya, dalam memperkirakan batas waktu penyelesaian suatu tugas, yaitu hanya mempertimbangkan berapa lama waktu yang dibutuhkan untuk menulis kode.
Belajar terus menerus bagi mereka yang menganalisis secara berlebihan. Itu hanya pekerjaan terus-menerus dengan orang-orang.

Hari keenam puluh

Sementara saya melakukan semua ini, tiba waktunya untuk memikirkan anggaran. Tentu saja, saya menemukan banyak hal menarik di mana kami membelanjakan uang kami. Misalnya, kami memiliki seluruh rak di pusat data terpisah dengan satu server FTP, yang digunakan oleh satu klien. Ternyata “...kami pindah, tapi dia tetap seperti itu, kami tidak mengubahnya.” Itu 2 tahun yang lalu.

Yang menarik adalah tagihan untuk layanan cloud. Saya yakin alasan utama tingginya tagihan cloud adalah para pengembang yang memiliki akses tak terbatas ke server untuk pertama kalinya dalam hidup mereka. Mereka tidak perlu bertanya: “Tolong beri saya server uji,” mereka bisa mengambilnya sendiri. Ditambah lagi, pengembang selalu ingin membangun sistem yang keren sehingga Facebook dan Netflix akan iri.

Namun pengembang tidak memiliki pengalaman dalam membeli server dan keterampilan menentukan ukuran server yang dibutuhkan, karena mereka tidak membutuhkannya sebelumnya. Dan mereka biasanya tidak begitu memahami perbedaan antara skalabilitas dan kinerja.

Hasil inventaris:

Kami meninggalkan pusat data yang sama.
Kami mengakhiri kontrak dengan 3 layanan log. Karena kami punya 5 di antaranya - setiap pengembang yang mulai bermain-main dengan sesuatu mengambil yang baru.
7 sistem AWS dimatikan. Sekali lagi, tidak ada yang menghentikan proyek-proyek yang mati; mereka semua terus bekerja.
Mengurangi biaya perangkat lunak sebanyak 6 kali lipat.

Hari ketujuh puluh lima

Waktu berlalu, dan dalam dua setengah bulan saya harus bertemu dengan dewan direksi. Dewan direksi kami tidak lebih baik atau lebih buruk dari yang lain; seperti semua dewan direksi, mereka ingin mengetahui segalanya. Orang-orang menginvestasikan uangnya dan ingin memahami seberapa sesuai apa yang kami lakukan dengan KPI yang ditetapkan.

Dewan direksi menerima banyak informasi setiap bulan: jumlah pengguna, pertumbuhan mereka, layanan apa yang mereka gunakan dan bagaimana caranya, kinerja dan produktivitas, dan terakhir, kecepatan pemuatan halaman rata-rata.

Satu-satunya masalah adalah saya percaya bahwa rata-rata adalah kejahatan murni. Namun sangat sulit menjelaskan hal ini kepada direksi. Mereka terbiasa beroperasi dengan angka agregat, dan bukan, misalnya, penyebaran waktu pemuatan per detik.

Ada beberapa hal menarik dalam hal ini. Misalnya, saya mengatakan bahwa kita perlu membagi lalu lintas antara server web yang terpisah tergantung pada jenis kontennya.

Yaitu, ColdFusion melewati Jetty dan nginx dan meluncurkan halaman-halamannya. Dan gambar, JS dan CSS melalui nginx terpisah dengan konfigurasinya sendiri. Ini adalah praktik yang cukup standar yang saya bicarakan saya menulis beberapa tahun yang lalu. Hasilnya, gambar dimuat lebih cepat, dan... kecepatan pemuatan rata-rata meningkat sebesar 200 ms.

Hal ini terjadi karena grafik dibuat berdasarkan data yang disertakan dengan Jetty. Artinya, konten cepat tidak termasuk dalam penghitungan - nilai rata-rata telah melonjak. Ini jelas bagi kami, kami tertawa, tapi bagaimana kami bisa menjelaskan kepada dewan direksi mengapa kami melakukan sesuatu dan keadaan menjadi lebih buruk sebesar 12%?

Hari kedelapan puluh lima

Di akhir bulan ketiga, saya menyadari bahwa ada satu hal yang tidak saya perhitungkan sama sekali: waktu. Semua yang saya bicarakan membutuhkan waktu.

Ini adalah kalender mingguan saya yang sebenarnya - hanya minggu kerja, tidak terlalu sibuk. Tidak ada cukup waktu untuk semuanya. Oleh karena itu, sekali lagi, Anda perlu merekrut orang-orang yang akan membantu Anda mengatasi masalah tersebut.

Kesimpulan

Bukan itu saja. Dalam cerita ini, saya bahkan belum mengetahui cara kami bekerja dengan produk dan mencoba menyesuaikan diri dengan gelombang umum, atau cara kami mengintegrasikan dukungan teknis, atau cara kami memecahkan masalah teknis lainnya. Misalnya, saya mengetahui secara tidak sengaja bahwa kami tidak menggunakan tabel terbesar di database SEQUENCE. Kami memiliki fungsi yang ditulis sendiri nextID, dan itu tidak digunakan dalam transaksi.

Masih ada sejuta hal serupa yang bisa kita bicarakan dalam waktu lama. Namun hal terpenting yang masih perlu disampaikan adalah budaya.

Budaya atau ketiadaan budayalah yang menyebabkan semua masalah lainnya. Kami mencoba membangun budaya di mana orang-orang:

tidak takut gagal;
belajar dari kesalahan;
berkolaborasi dengan tim lain;
mengambil inisiatif;
mengambil tanggung jawab;
menyambut hasilnya sebagai tujuan;
merayakan kesuksesan.

Dengan ini segalanya akan datang.

Leon Api di Twitter, facebook dan medium.

Ada dua strategi mengenai warisan: hindari bekerja dengannya dengan cara apa pun, atau dengan berani mengatasi kesulitan yang terkait. Kami c DevOpsConf Kami mengambil jalur kedua, mengubah proses dan pendekatan. Bergabunglah dengan kami Youtube, milis и telegram, dan bersama-sama kita akan menerapkan budaya DevOps.

Sumber: www.habr.com

Warisan sistem dan proses lama atau 90 hari pertama sebagai CTO