Dikawruhi yen kompetensi CTO dites mung kaping pindho dheweke nindakake peran iki. Amarga iku siji bab kanggo bisa ing perusahaan kanggo sawetara taun, berkembang karo lan, ing konteks budaya padha, mboko sithik nampa tanggung jawab liyane. Lan iku cukup liyane teka langsung menyang posisi direktur technical ing perusahaan karo bagasi warisan lan Bunch saka masalah rapi disapu ing karpet.

Ing pangertèn iki, pengalaman Leon Fire, kang nuduhake ing DevOpsConf, ora persis unik, nanging ping pingan dening pengalaman lan nomer peran beda sing ngatur kanggo nyoba liwat Course saka 20 taun, iku banget migunani. Ing ngisor potongan kasebut ana kronologi acara sajrone 90 dina lan akeh crita sing nyenengake nalika kedadeyan karo wong liya, nanging ora nyenengake kanggo ngadhepi wong liya.

Leon ngomong kanthi warna-warni ing basa Rusia, dadi yen sampeyan duwe 35-40 menit, aku nyaranake nonton video kasebut. Versi teks kanggo ngirit wektu ing ngisor iki.

Versi pisanan saka laporan kasebut minangka deskripsi sing terstruktur babagan nggarap wong lan proses, ngemot rekomendasi sing migunani. Nanging dheweke ora ngandhani kabeh kejutan sing ditemoni ing dalan. Mulane, aku ngganti format lan menehi masalah sing muncul ing ngarepku kaya jack-in-the-box ing perusahaan anyar, lan cara kanggo ngrampungake kanthi urutan kronologis.

Sewulan sadurunge

Kaya akeh crita apik, iki diwiwiti kanthi alkohol. Kita lungguh karo kanca-kanca ing bar, lan kaya sing dikarepake ing antarane spesialis IT, kabeh wong nangis babagan masalahe. Salah siji saka wong-wong mau mung ngganti proyek lan ngomong babagan masalah teknologi, lan karo wong, lan tim. Luwih aku ngrungokake, aku ngerti yen dheweke mung kudu nyewa aku, amarga iki minangka jinis masalah sing wis dakrampungake sajrone 15 taun kepungkur. Aku ngomong ngono, lan dina sabanjure kita ketemu ing lingkungan kerja. Perusahaan kasebut diarani Strategi Pengajaran.

Strategi Pengajaran minangka pimpinan pasar ing kurikulum kanggo bocah cilik wiwit lair nganti umur telung taun. Perusahaan "kertas" tradisional wis umur 40 taun, lan versi platform SaaS digital umure 10. Relatif bubar, proses adaptasi teknologi digital kanggo standar perusahaan diwiwiti. Versi "anyar" diluncurake ing 2017 lan meh padha karo sing lawas, mung luwih elek.

Sing paling menarik yaiku lalu lintas perusahaan iki bisa ditebak - saben dina, saka taun nganti taun, sampeyan bisa kanthi jelas prédhiksi jumlah wong sing bakal teka lan kapan. Contone, antarane jam 13 lan 15 sore kabeh bocah ing taman kanak-kanak turu lan guru wiwit ngetik informasi. Lan iki kedadeyan saben dina, kajaba akhir minggu, amarga meh ora ana sing kerja ing akhir minggu.

Looking ahead sethitik, Aku bakal Wigati sing aku miwiti karya sak periode lalu lintas taunan paling dhuwur, kang menarik kanggo macem-macem alasan.

Platform kasebut, sing umure mung 2 taun, duwe tumpukan aneh: ColdFusion & SQL Server saka 2008. ColdFusion, yen sampeyan ora ngerti, lan paling kamungkinan sampeyan ora ngerti, iku PHP perusahaan sing metu ing agêng-90s, lan wiwit iku aku wis ora krungu bab iku. Uga ana: Ruby, MySQL, PostgreSQL, Java, Go, Python. Nanging monolith utama mlaku ing ColdFusion lan SQL Server.

Masalah

Nalika aku ngobrol karo karyawan perusahaan babagan karya lan masalah apa wae sing ditemoni, aku luwih ngerti yen masalah kasebut ora mung teknis. Oke, teknologi wis lawas - lan ora bisa ditindakake, nanging ana masalah karo tim lan proses, lan perusahaan wiwit ngerti iki.

Biasane, teknisi dheweke lungguh ing pojok lan nindakake sawetara pakaryan. Nanging luwih akeh bisnis wiwit ngliwati versi digital. Mulane, ing taun kepungkur sadurunge aku miwiti kerja, sing anyar muncul ing perusahaan: dewan direksi, CTO, CPO lan direktur QA. Sing, perusahaan wiwit nandur modal ing sektor teknologi.

Tilas warisan abot ora mung ana ing sistem kasebut. Perusahaan kasebut nduweni proses warisan, wong warisan, budaya warisan. Kabeh iki kudu diganti. Aku panginten sing mesthi ora bakal mboseni, lan mutusaké kanggo nyoba.

Rong dina sadurunge

Rong dina sadurunge miwiti proyek anyar, aku teka ing kantor, ngisi dokumen pungkasan, ketemu tim, lan nemokake yen tim lagi berjuang karo masalah nalika iku. Iku wektu loading kaca rata-rata mlumpat dadi 4 detik, yaiku, kaping 2.

Miturut grafik, ana kedadeyan sing jelas, lan ora jelas apa. Ternyata masalah kasebut yaiku latensi jaringan ing pusat data: latensi 5 ms ing pusat data dadi 2 detik kanggo pangguna. Aku ora ngerti apa iki kedaden, nanging ing kasus dadi dikenal sing masalah ana ing pusat data.

Dina pisanan

Rong dina liwati lan ing dina pisanan kerja aku nemokake manawa masalah kasebut ora ilang.

Sajrone rong dina, kaca pangguna rata-rata dimuat sajrone 4 detik. Aku takon yen dheweke nemokake apa masalahe.

- Ya, kita mbukak tiket.
- lan?
- Inggih, padha durung mangsuli kita.

Banjur aku nyadari yen kabeh sing wis dakcritakake sadurunge mung pucuk gunung es sing kudu daklawan.

Ana kutipan apik sing cocog banget iki:

"Kadhangkala kanggo ngganti teknologi sampeyan kudu ngganti organisasi."

Nanging wiwit aku miwiti kerja ing wektu paling sibuk ing taun, aku kudu ndeleng loro opsi kanggo ngrampungake masalah: loro cepet lan long-term. Lan miwiti karo apa sing kritis saiki.

Tiga dina

Dadi, loading luwih 4 detik, lan saka 13 kanggo 15 puncak paling gedhe.

Ing dina katelu sajrone wektu iki, kacepetan download katon kaya iki:

Saka sudut pandangku, ora ana sing bisa digunakake. Saka sudut pandang wong liya, mlaku rada alon tinimbang biasane. Nanging ora kedadeyan kaya ngono-iku masalah serius.

Aku nyoba kanggo gawe uwong yakin tim, kang padha njawab sing padha mung mbutuhake server liyane. Iki, mesthi, minangka solusi kanggo masalah kasebut, nanging ora mung siji-sijine lan paling efektif. Aku takon kenapa ora cukup server, apa volume lalu lintas. Aku extrapolated data lan ketemu sing kita duwe kira-kira 150 panjalukan per detik, kang, ing asas, tumiba ing watesan cukup.

Nanging kita kudu ora lali yen sadurunge njaluk jawaban sing bener, sampeyan kudu takon pitakonan sing bener. Pitakonanku sabanjure yaiku: pirang-pirang server frontend sing kita duwe? Jawaban "dadi bingung" - kita duwe 17 server frontend!

— Aku isin takon, nanging 150 dibagi 17 menehi bab 8? Apa sampeyan ngomong sing saben server ngidini 8 panjalukan per detik, lan yen sesuk ana 160 panjalukan saben detik, kita kudu 2 server liyane?

Mesthi wae, kita ora butuh server tambahan. Solusi kasebut ana ing kode kasebut, lan ing permukaan:

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

Ana fungsi getCurrentClass(), amarga kabeh ing situs bisa digunakake ing konteks kelas - sing bener. Lan kanggo fungsi siji iki ing saben kaca ana 200+ panjalukan.

Solusi kanthi cara iki gampang banget, sampeyan ora kudu nulis ulang apa-apa: mung aja njaluk informasi sing padha maneh.

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

Aku seneng banget amarga aku mutusake yen ing dina katelu aku nemokake masalah utama. Naif kaya aku, iki mung salah siji saka akeh masalah.

Nanging ngrampungake masalah pisanan iki nyebabake grafik luwih murah.

Ing wektu sing padha, kita nindakake optimasi liyane. Ana akeh perkara sing bisa didandani. Contone, ing dina katelu sing padha aku nemokake yen ana cache ing sistem sawise kabeh (ing kawitan aku panginten sing kabeh panjalukan teka langsung saka database). Nalika aku mikir cache, aku mikir Redis standar utawa Memcached. Nanging aku mung siji sing mikir, amarga sistem kasebut nggunakake MongoDB lan SQL Server kanggo caching - sing padha karo data sing diwaca.

Dina sepuluh

Minggu pisanan aku ngatasi masalah sing kudu dirampungake saiki. Nang endi wae ing minggu kapindho, aku teka ing stand-up kanggo sepisanan kanggo komunikasi karo tim, kanggo ndeleng apa sing kedadeyan lan kepiye proses kabeh.

Ana sing menarik ditemokake maneh. Tim kasebut kalebu: 18 pangembang; 8 panguji; 3 pangurus; 2 arsitek. Lan kabeh padha melu ritual umum, yaiku, luwih saka 30 wong teka ing stand-up saben esuk lan ngandhani apa sing ditindakake. Cetha yen rapat kasebut ora njupuk 5 utawa 15 menit. Ora ana sing ngrungokake sapa wae amarga saben wong nggarap sistem sing beda-beda. Ing wangun iki, 2-3 tiket saben jam kanggo sesi dandan wis asil apik.

Babagan pisanan sing ditindakake yaiku pamisah tim dadi pirang-pirang lini produk. Kanggo bagean lan sistem sing beda, kita nyedhiyakake tim sing kapisah, kalebu pangembang, penguji, manajer produk, lan analis bisnis.

Akibaté, kita entuk:

Ngurangi stand-up lan rapat umum.
Pengetahuan subyek babagan produk.
Rasa nduweni. Nalika wong digunakake kanggo tinker karo sistem kabeh wektu, padha ngerti sing wong liya paling kamungkinan kudu bisa karo kewan omo, nanging ora piyambak.
Kolaborasi antarane klompok. Ora perlu dikandhakake, QA ora akeh komunikasi karo programer sadurunge, produk kasebut nindakake dhewe, lsp. Saiki padha duwe titik tanggung jawab umum.

Kita utamane fokus ing efisiensi, produktivitas lan kualitas - iki minangka masalah sing nyoba diatasi kanthi transformasi tim.

Dina sewelas

Ing proses ngganti struktur tim, aku nemokake carane ngetung critaTCTerms. 1 SP padha karo sedina, lan saben tiket ngemot SP kanggo pangembangan lan QA, yaiku, paling ora 2 SP.

Kepiye carane aku nemokake iki?

Kita nemokake bug: ing salah sawijining laporan, ing ngendi tanggal wiwitan lan pungkasan periode sing dibutuhake laporan kasebut dilebokake, dina pungkasan ora dianggep. Sing, ing endi wae ing panyuwunan ora ana <=, nanging mung <. Aku iki marang sing iki telung Story Points, sing 3 dina.

Sawise iki kita:

Sistem rating Story Points wis direvisi. Saiki ndandani bug cilik sing bisa dilewati kanthi cepet liwat sistem tekan pangguna luwih cepet.
Kita miwiti nggabungake tiket sing gegandhengan kanggo pangembangan lan tes. Sadurunge, saben tiket, saben bug minangka ekosistem sing ditutup, ora ana gandhengane karo apa wae. Ngganti telung tombol ing siji kaca bisa dadi telung tiket sing beda karo telung proses QA sing beda tinimbang siji tes otomatis saben kaca.
Kita miwiti nggarap pangembang babagan pendekatan kanggo ngira biaya tenaga kerja. Telung dina kanggo ngganti siji tombol ora lucu.

Dina kaping rongpuluh

Nang endi wae ing tengah sasi kapisan, kahanan stabil sethitik, Aku figured metu apa Sejatine kedados, lan wis wiwit katon menyang mangsa lan mikir bab solusi long-term.

Tujuan jangka panjang:

Platform sing dikelola. Atusan panjalukan ing saben kaca ora serius.
Tren sing bisa diramal. Ana puncak lalu lintas periodik sing sepisanan ora ana hubungane karo metrik liyane - kita kudu ngerti sebabe kedadeyan kasebut lan sinau prédhiksi.
Ekspansi platform. Bisnis terus berkembang, akeh pangguna sing teka, lan lalu lintas saya tambah.

Ing jaman biyen asring diucapake: "Ayo nulis maneh kabeh ing [basa / kerangka], kabeh bakal luwih apik!"

Ing kasus paling iki ora bisa, iku apik yen nulis ulang bisa ing kabeh. Mula, kita kudu nggawe peta dalan - strategi khusus sing nggambarake langkah demi langkah kepiye tujuan bisnis bakal digayuh (apa sing bakal ditindakake lan kenapa), yaiku:

nggambarake misi lan tujuan proyek;
prioritas tujuan utama;
ngemot jadwal kanggo nggayuh.

Sadurunge iki, ora ana sing ngomong karo tim babagan tujuan owah-owahan sing ditindakake. Iki mbutuhake metrik sukses sing tepat. Kanggo pisanan ing sajarah perusahaan, kita nyetel KPI kanggo grup teknis, lan indikator kasebut diikat karo organisasi.

Tegese, KPI organisasi didhukung dening tim, lan KPI tim didhukung dening KPI individu. Yen ora, yen KPI teknologi ora cocog karo organisasi, mula saben wong narik kemul ing awake dhewe.

Contone, salah sawijining KPI organisasi nambah pangsa pasar liwat produk anyar.

Kepiye sampeyan bisa ndhukung tujuan supaya luwih akeh produk anyar?

Kaping pisanan, kita pengin luwih akeh wektu ngembangake produk anyar tinimbang ndandani cacat. Iki minangka solusi logis sing gampang diukur.
Kapindho, kita pengin ndhukung paningkatan volume transaksi, amarga luwih akeh pangsa pasar, luwih akeh pangguna lan, kanthi mangkono, luwih akeh lalu lintas.

Banjur KPI individu sing bisa dieksekusi ing grup kasebut, umpamane, ana ing papan sing ana cacat utama. Yen sampeyan fokus khusus ing bagean iki, sampeyan bisa mesthekake yen ana cacat sing luwih sithik, banjur wektu kanggo ngembangake produk anyar lan maneh kanggo ndhukung KPI organisasi bakal tambah.

Mangkono, saben keputusan, kalebu kode nulis ulang, kudu ndhukung tujuan tartamtu sing wis disetel perusahaan kanggo kita (pertumbuhan organisasi, fitur anyar, rekrutmen).

Sajrone proses iki, ana perkara sing menarik, sing dadi warta ora mung kanggo teknisi, nanging umume ing perusahaan: kabeh tiket kudu fokus ing paling ora siji KPI. Yaiku, yen produk ujar manawa pengin nggawe fitur anyar, pitakonan pisanan kudu ditakoni: "Apa KPI sing didhukung fitur iki?" Yen ora, banjur nuwun - misale jek kaya fitur sing ora perlu.

Dina telung puluh

Ing pungkasan sasi, aku nemokake nuansa liyane: ora ana siji ing tim Ops sing tau ndeleng kontrak sing kita lakoni karo klien. Sampeyan bisa uga takon kenapa sampeyan kudu ndeleng kontak.

Kaping pisanan, amarga SLA ditemtokake ing kontrak.
Kapindho, SLA kabeh beda. Saben klien teka kanthi syarat dhewe, lan departemen dodolan mlebu tanpa ndeleng.

Nuansa liyane sing menarik yaiku kontrak karo salah sawijining klien paling gedhe nyatakake yen kabeh versi piranti lunak sing didhukung dening platform kasebut kudu n-1, yaiku, dudu versi paling anyar, nanging versi penultimate.

Cetha sepira adoh saka n-1 yen platform kasebut adhedhasar ColdFusion lan SQL Server 2008, sing ora didhukung maneh ing wulan Juli.

Dina patang puluh lima

Kira-kira tengah sasi kapindho aku wis cukup wektu kanggo lungguh lan nindakake Nilaistreampemetaan rampung kanggo kabeh proses. Iki minangka langkah-langkah sing kudu ditindakake, saka nggawe produk nganti dikirim menyang konsumen, lan kudu diterangake kanthi rinci.

Sampeyan ngilangi proses kasebut dadi potongan-potongan cilik lan ndeleng apa sing mbutuhake wektu akeh, apa sing bisa dioptimalake, ditingkatake, lsp. Contone, sepira suwene panjaluk produk bisa ditindakake, kapan tekan tiket sing bisa ditindakake pangembang, QA, lsp. Supaya sampeyan ndeleng saben langkah individu kanthi rinci lan mikir babagan apa sing bisa dioptimalake.

Nalika aku nindakake iki, ana rong perkara sing narik kawigatenku:

persentasi dhuwur saka tiket bali saka QA bali kanggo pangembang;
review request narik njupuk dawa banget.

Masalahe yaiku iki minangka kesimpulan kaya: Iku misale jek njupuk akeh wektu, nanging kita ora yakin suwene.

"Sampeyan ora bisa nambah apa sing ora bisa diukur."

Kepiye carane mbenerake sepira serius masalah kasebut? Apa mbuwang dina utawa jam?

Kanggo ngukur iki, kita nambahake sawetara langkah menyang proses Jira: "siap kanggo dev" lan "siap kanggo QA" kanggo ngukur suwene saben tiket ngenteni lan kaping pirang-pirang bali menyang langkah tartamtu.

Kita uga nambah "ing review" kanggo ngerti carane akeh tiket rata-rata kanggo review, lan saka iki sampeyan bisa miwiti nari. Kita duwe metrik sistem, saiki kita nambah metrik anyar lan wiwit ngukur:

Efisiensi proses: kinerja lan ngrancang / dikirim.
Kualitas proses: jumlah cacat, cacat saka QA.

Iku pancene mbantu kanggo ngerti apa sing mlaku lan apa sing ora apik.

Dina kaping seket

Iki kabeh, mesthi, apik lan menarik, nanging ing pungkasan sasi kapindho ana kedadeyan sing, ing asas, bisa ditebak, sanajan aku ora ngarepake skala kasebut. Wong-wong wiwit lunga amarga manajemen puncak wis ganti. Wong anyar teka menyang manajemen lan wiwit ngganti kabeh, lan sing lawas mandheg. Lan biasane ing perusahaan sing umure pirang-pirang taun, kabeh wong dadi kanca lan kabeh wong ngerti.

Iki wis samesthine, nanging skala PHK ora dikarepke. Contone, ing siji minggu loro tim ndadékaké bebarengan ngirim mundur saka karsane dhewe. Mulane, aku kudu ora mung lali bab masalah liyane, nanging fokus ing nggawe tim. Iki minangka masalah sing dawa lan angel diatasi, nanging kudu ditangani amarga aku pengin nylametake wong-wong sing isih ana (utawa umume). Sampeyan kudu piye wae nanggepi kasunyatan sing wong ninggalake kanggo njaga moral ing tim.

Ing teori, iki apik: wong anyar teka sing wis lengkap carte blanche, sing bisa ngevaluasi skills tim lan ngganti personel. Nyatane, sampeyan ora bisa mung nggawa wong anyar amarga akeh alasan. Balance tansah dibutuhake.

Lawas lan anyar. Kita kudu njaga wong tuwa sing bisa ngganti lan ndhukung misi kasebut. Nanging ing wektu sing padha, kita kudu nggawa getih anyar, kita bakal ngomong babagan iki mengko.
Pengalaman. Aku ngomong akeh karo junior apik sing semangat lan pengin bisa karo kita. Nanging aku ora bisa njupuk wong-wong mau amarga ana ora cukup senior kanggo ndhukung juniors lan tumindak minangka mentor kanggo wong-wong mau. Sampeyan perlu kanggo rekrut pisanan ndhuwur lan mung nom.
Wortel lan tongkat.

Aku ora duwe jawaban apik kanggo pitakonan apa imbangan tengen, carane kanggo njaga, carane akeh wong kanggo tetep lan carane akeh kanggo push. Iki minangka proses murni individu.

Dina seket siji

Aku wiwit ndeleng kanthi rapet ing tim kanggo ngerti sapa sing duwe, lan sepisan maneh aku kelingan:

"Paling akeh masalah yaiku masalah wong."

Aku wis nemokake manawa tim kasebut - loro Dev lan Ops - duwe telung masalah gedhe:

Marem karo kahanan saiki.
Kurang tanggung jawab - amarga ora ana sing nggawa asil karya para pemain kanggo pengaruhe bisnis.
Wedi owah-owahan.

Owah-owahan tansah njupuk sampeyan metu saka zona nyaman, lan wong sing luwih enom, sing luwih ora seneng owah-owahan amarga padha ora ngerti apa lan padha ora ngerti carane. Jawaban sing paling umum sing dakrungu yaiku, "Kita durung nate nglakoni." Menapa malih, tekan titik absurdity lengkap - owah-owahan slightest ora bisa njupuk Panggonan tanpa wong kang nesu. Lan ora preduli sepira owah-owahan mengaruhi karyane, wong-wong kandha, ”Ora, kenapa? Iki ora bakal bisa."

Nanging sampeyan ora bisa dadi luwih apik tanpa ngganti apa-apa.

Aku duwe obrolan sing ora masuk akal karo karyawan, aku ngandhani ide kanggo optimasi, sing dakkandhakake:
- Oh, sampeyan ora weruh apa sing kita duwe taun kepungkur!
- Lha terus piye?
"Saiki luwih apik tinimbang saiki."
- Dadi, ora bisa luwih apik?
- Kanggo apa?

Pitakonan apik - kenapa? Kaya-kaya saiki luwih apik tinimbang saiki, mula kabeh wis cukup. Iki ndadékaké kanggo lack saka tanggung jawab, kang pancen normal ing asas. Kaya sing dakkandhakake, klompok teknis rada adoh. Perusahaan percaya yen kudu ana, nanging ora ana sing nate nyetel standar. Dhukungan teknis ora nate ndeleng SLA, mula cukup "ditrima" kanggo grup kasebut (lan iki paling saya kaget):

12 detik loading;
5-10 menit downtime saben release;
Ngatasi masalah kritis njupuk dina lan minggu;
kekurangan personel tugas 24x7 / on-call.

Ora ana sing nate takon kenapa ora luwih apik, lan ora ana sing ngerti yen ora kudu kaya ngono.

Minangka bonus, ana siji masalah liyane: kurang pengalaman. Para senior lunga, lan tim enom isih tuwuh ing rezim sadurunge lan diracuni.

Ing ndhuwur kabeh iki, wong uga wedi gagal lan katon ora kompeten. Iki ditulis ing kasunyatan sing, pisanan, padha ing kahanan ora njaluk bantuan. Kaping pirang-pirang kita ngobrol kanthi klompok lan individu, lan aku ujar, "Aja takon yen sampeyan ora ngerti carane nindakake." Aku yakin karo aku lan ngerti yen aku bisa ngatasi masalah apa wae, nanging butuh wektu. Mulane, yen aku bisa takon wong sing ngerti carane ngatasi ing 10 menit, aku bakal takon. Kurang pengalaman, luwih wedi sampeyan takon amarga sampeyan mikir sampeyan bakal dianggep ora kompeten.

Wedi iki takon pitakonan manifests dhewe ing cara menarik. Contone, sampeyan takon: "Kepiye sampeyan nindakake tugas iki?" "Masih sawetara jam, aku wis rampung." Dina sabanjure sampeyan takon maneh, sampeyan entuk wangsulan yen kabeh apik, nanging ana masalah, mesthine bakal siap ing pungkasan dina. Dina liyane liwat, lan nganti sampeyan wis pinned menyang tembok lan dipeksa kanggo ngomong karo wong, iki terus. Wong kepengin ngrampungake masalah dhewe; dheweke percaya yen ora ngrampungake dhewe, iku bakal dadi kegagalan gedhe.

Mulane pangembang inflated prakiraan. Iku anekdot padha, nalika padha ngrembug tugas tartamtu, padha menehi kula tokoh sing aku kaget banget. Sing dakkandhakake yen ing perkiraan pangembang, pangembang kalebu wektu yen tiket bakal bali saka QA, amarga bakal nemokake kesalahan ing kana, lan wektu sing bakal ditindakake PR, lan wektu nalika wong sing kudu mriksa. bakal sibuk - yaiku, kabeh, apa wae sing bisa.

Kapindho, wong sing wedi katon ora kompeten overanalisis. Nalika sampeyan ngomong apa sing kudu ditindakake, mula: "Ora, kepiye yen kita mikir babagan iki?" Ing pangertèn iki, perusahaan kita ora unik; iki minangka masalah standar kanggo wong enom.

Kanggo nanggepi, aku ngenalake praktik ing ngisor iki:

Aturan 30 menit. Yen sampeyan ora bisa ngatasi masalah ing setengah jam, takon wong kanggo bantuan. Iki dianggo kanthi macem-macem derajat sukses, amarga wong isih ora takon, nanging paling proses wis diwiwiti.
Ngilangi kabeh nanging inti, ing ngira deadline kanggo ngrampungake tugas, sing, count mung suwene iku bakal njupuk kanggo nulis kode.
Sinau terus-terusan kanggo sing overanalyze. Iku mung karya pancet karo wong.

Dina kaping sawidak

Nalika aku nindakake kabeh iki, iku wektu kanggo nemtokake budget. Mesthi, aku nemokake akeh perkara sing menarik ing ngendi kita ngentekake dhuwit. Contone, kita duwe rak kabeh ing pusat data sing kapisah karo siji server FTP, sing digunakake dening siji klien. Ternyata "... kita pindhah, nanging dheweke tetep kaya ngono, kita ora ngganti dheweke." Iku 2 taun kepungkur.

Kapentingan khusus yaiku tagihan kanggo layanan awan. Aku yakin alasan utama tagihan awan sing dhuwur yaiku para pangembang sing duwe akses tanpa wates menyang server kanggo pisanan ing urip. Padha ora perlu takon: "Mangga menehi kula server test,"Dheweke bisa njupuk dhewe. Kajaba iku, pangembang mesthi pengin nggawe sistem sing apik banget sing bakal cemburu Facebook lan Netflix.

Nanging pangembang ora duwe pengalaman kanggo tuku server lan katrampilan nemtokake ukuran server sing dibutuhake, amarga dheweke ora butuh sadurunge. Lan biasane ora ngerti bedane skalabilitas lan kinerja.

Hasil inventaris:

Kita ninggalake pusat data sing padha.
Kita mungkasi kontrak karo 3 layanan log. Amarga kita duwe 5 wong - saben pangembang sing wiwit main karo apa wae njupuk sing anyar.
7 sistem AWS dipateni. Maneh, ora ana sing mandhegake proyek sing wis mati, kabeh terus kerja.
Biaya piranti lunak suda kaping 6.

Dina pitung puluh lima

Wektu liwati, lan rong wulan setengah aku kudu ketemu karo dewan direksi. Dewan direksi kita ora luwih apik utawa luwih ala tinimbang liyane; kaya kabeh dewan direksi, dheweke kepengin ngerti kabeh. Wong nandur modal dhuwit lan pengin ngerti sepira apa sing kita lakoni cocog karo KPI sing disetel.

Dewan direksi nampa akeh informasi saben sasi: jumlah pangguna, wutah, layanan apa sing digunakake lan carane, kinerja lan produktivitas, lan pungkasane, kacepetan loading kaca rata-rata.

Mung masalah iku aku pracaya sing rata-rata iku murni ala. Nanging angel banget kanggo nerangake babagan iki menyang dewan direksi. Lagi rakulino kanggo operasi karo nomer dikumpulake, lan ora, contone, panyebaran kaping loading per detik.

Ana sawetara titik menarik ing babagan iki. Contone, aku ujar manawa kita kudu pamisah lalu lintas ing antarane server web sing kapisah gumantung saka jinis konten.

Yaiku, ColdFusion ngliwati Jetty lan nginx lan mbukak kaca kasebut. Lan gambar, JS lan CSS ngliwati nginx sing kapisah kanthi konfigurasi dhewe. Iki minangka praktik sing cukup standar sing dakkandhakake wrote sawetara taun kepungkur. Akibaté, gambar mbukak luwih cepet, lan ... kacepetan loading rata-rata wis tambah dening 200 ms.

Iki kedadeyan amarga grafik kasebut digawe adhedhasar data sing diwenehake karo Jetty. Tegese, isi cepet ora kalebu ing pitungan - nilai rata-rata wis mlumpat. Iki wis jelas kanggo kita, kita ngguyu, nanging kepiye carane bisa nerangake marang dewan direksi kenapa kita nindakake apa-apa lan dadi luwih elek nganti 12%?

Dina wolung puluh lima

Ing pungkasan sasi katelu, aku nyadari yen ana siji bab sing ora daketung babar pisan: wektu. Kabeh sing dakkandhakake butuh wektu.

Iki tanggalan mingguanku sing nyata - mung minggu kerja, ora sibuk banget. Ora ana wektu sing cukup kanggo kabeh. Mulane, maneh, sampeyan kudu ngrekrut wong sing bakal mbantu sampeyan ngatasi masalah kasebut.

kesimpulan

Ora mung kuwi. Ing crita iki, aku malah durung ngerti carane kita makarya karo produk lan nyoba kanggo nyetel ing gelombang umum, utawa carane kita Integrasi technical support, utawa carane kita ditanggulangi masalah technical liyane. Contone, aku sinau kanthi ora sengaja yen ing tabel paling gedhe ing database sing ora digunakake SEQUENCE. Kita duwe fungsi sing ditulis dhewe nextID, lan ora digunakake ing transaksi.

Ana yuta liyane sing padha bisa kita ngomong bab kanggo dangu. Nanging sing paling penting sing isih kudu diucapake yaiku budaya.

Budaya utawa kekurangane sing nyebabake kabeh masalah liyane. Kita nyoba mbangun budaya ing ngendi wong:

ora wedi gagal;
sinau saka kesalahan;
kolaborasi karo tim liyane;
njupuk inisiatif;
njupuk tanggung jawab;
welcome asil minangka gol;
ngrayakake sukses.

Kanthi iki kabeh liyane bakal teka.

Leon Fire ing twitter, facebook lan ing medium.

Ana rong strategi babagan warisan: supaya ora bisa digunakake kanthi kabeh biaya, utawa kanthi wani ngatasi kesulitan sing ana gandhengane. Kita c DevOpsConf Kita njupuk dalan kapindho, ngganti proses lan pendekatan. Gabung ing youtube, milis и telegram, lan bebarengan kita bakal ngetrapake budaya DevOps.

Source: www.habr.com

Warisan sistem lan proses warisan utawa 90 dina pisanan minangka CTO