Kiwari, jasa Bitrix24 henteu ngagaduhan ratusan gigabit lalu lintas, sareng henteu gaduh armada server anu ageung (sanaos, tangtosna, aya sababaraha anu parantos aya). Tapi pikeun seueur klien, éta mangrupikeun alat utama pikeun damel di perusahaan; éta mangrupikeun aplikasi kritis bisnis anu nyata. Ku alatan éta, teu aya cara pikeun ragrag. Kumaha upami kacilakaan éta kajantenan, tapi jasa éta "cageur" gancang-gancang dugi ka teu aya anu terang nanaon? Sareng kumaha tiasa ngalaksanakeun failover tanpa kaleungitan kualitas padamelan sareng jumlah klien? Alexander Demidov, diréktur jasa awan di Bitrix24, nyarios pikeun blog urang ngeunaan kumaha sistem réservasi parantos mekar salami 7 taun ayana produk.
"Kami ngaluncurkeun Bitrix24 salaku SaaS 7 sababaraha taun ka pengker. Kasusah utama sigana di handap ieu: sateuacan diluncurkeun sacara umum salaku SaaS, produk ieu ngan ukur aya dina format solusi kotak. Klién ngagaleuh ti kami, di-host dina serverna, nyetél portal perusahaan - solusi umum pikeun komunikasi karyawan, neundeun file, manajemén tugas, CRM, éta waé. Sareng ku 2012, urang mutuskeun yén urang badé ngaluncurkeun éta salaku SaaS, ngatur éta nyalira, mastikeun kasabaran sareng kabébasan. Kami ngagaduhan pangalaman sapanjang jalan, sabab dugi ka ayeuna urang ngan saukur teu gaduh - kami ngan ukur produsén parangkat lunak, sanés panyadia jasa.
Nalika ngaluncurkeun jasa, kami ngartos yén anu paling penting nyaéta pikeun mastikeun kasabaran kasalahan, réliabilitas sareng kasadiaan jasa anu tetep, sabab upami anjeun ngagaduhan halaman wéb biasa anu sederhana, toko, contona, sareng tumiba ka anjeun sareng linggih di dinya. sajam, ngan anjeun sangsara, anjeun leungit pesenan , anjeun leungit klien, tapi pikeun klien anjeun sorangan, ieu teu kritis pisan pikeun anjeunna. Anjeunna kesel, tangtosna, tapi manéhna indit jeung meuli eta dina situs séjén. Sareng upami ieu mangrupikeun aplikasi dimana sadaya padamelan dina perusahaan, komunikasi, kaputusan dihijikeun, maka anu paling penting nyaéta pikeun kéngingkeun kapercayaan pangguna, nyaéta, henteu ngantepkeun aranjeunna sareng henteu murag. Kusabab sagala pagawean bisa eureun lamun hal di jero teu jalan.
Bitrix.24 sakumaha SaaS
Urang ngumpul prototipe munggaran sataun saméméh peluncuran umum, dina 2011. Kami ngarakit éta sakitar saminggu, ningal éta, dipintal - éta malah tiasa dianggo. Nyaéta, anjeun tiasa lebet kana formulir, lebetkeun nami portal di dinya, portal énggal bakal dibuka, sareng basis pangguna bakal didamel. Urang nempo eta, ditaksir produk dina prinsipna, scrapped eta, sarta terus nyaring eta salila sataun. Kusabab kami ngagaduhan tugas anu ageung: kami henteu hoyong ngadamel dua dasar kode anu béda, kami henteu hoyong ngadukung produk rangkep anu misah, solusi awan anu misah - kami hoyong ngalakukeun éta sadayana dina hiji kode.
Aplikasi wéb anu biasa dina waktos éta mangrupikeun hiji server dimana sababaraha kode PHP dijalankeun, database MySQL, file diunggah, dokumén, gambar disimpen dina folder unggah - saé, éta sadayana tiasa dianggo. Hanjakalna, mustahil pikeun ngaluncurkeun jasa wéb anu stabil sacara kritis ngagunakeun ieu. Aya, cache disebarkeun teu dirojong, réplikasi database teu didukung.
Urang ngarumuskeun sarat: ieu téh kamampuhan pikeun lokasina di lokasi béda, ngarojong réplikasi, sarta ideally lokasina di puseur data sebaran géografis béda. Misahkeun logika produk sareng, kanyataanna, neundeun data. Mampuh skala dinamis dumasar kana beban, sareng toleran statik sadayana. Tina pertimbangan ieu, kanyataanna, sarat pikeun produkna muncul, anu kami sampurnakeun salami sataun. Antukna, dina platform, anu tétéla ngahiji - pikeun solusi kotak, pikeun jasa kami sorangan - kami ngadamel dukungan pikeun hal-hal anu kami butuhkeun. Rojongan pikeun réplikasi mysql dina tingkat produk sorangan: nyaéta, pamekar anu nyerat kodeu henteu mikirkeun kumaha pamenta na bakal disebarkeun, anjeunna nganggo api kami, sareng urang terang kumaha leres ngadistribusikaeun nyerat sareng maca pamundut antara master. jeung budak.
Kami parantos ngadamel dukungan dina tingkat produk pikeun sababaraha panyimpen obyék awan: panyimpenan google, amazon s3, ditambah dukungan pikeun tumpukan kabuka Swift. Ku alatan éta, ieu merenah duanana pikeun urang salaku layanan sarta pamekar anu dianggo kalayan solusi rangkep: lamun aranjeunna ngan ngagunakeun API kami pikeun digawé, maranéhna teu mikir ngeunaan dimana file pamustunganana bakal disimpen, lokal dina sistem file atawa dina panyimpenan file obyék.
Hasilna, urang langsung mutuskeun yén urang bakal cagar di tingkat sakabéh puseur data. Dina 2012, urang diluncurkeun sagemblengna dina Amazon AWS sabab urang geus boga pangalaman jeung platform ieu - ramatloka urang sorangan ieu hosted dinya. Kami katarik kanyataan yén di unggal daérah Amazon ngagaduhan sababaraha zona kasadiaan - kanyataanna, (dina terminologina) sababaraha pusat data anu langkung atanapi kirang bebas saling sareng ngamungkinkeun urang pikeun cagar dina tingkat pusat data sadayana: lamun ujug-ujug gagal, database anu replicated master-master, server aplikasi wéb dicadangkeun, sarta data statik dipindahkeun ka gudang obyék s3. Bebanna saimbang - dina waktos éta ku Amazon elb, tapi sakedap deui kami dugi ka penyeimbang beban urang sorangan, sabab kami peryogi logika anu langkung kompleks.
Naon anu aranjeunna pikahoyong nyaéta naon anu aranjeunna kéngingkeun ...
Sadaya hal dasar anu urang hoyong mastikeun - kasabaran kasalahan tina server sorangan, aplikasi wéb, pangkalan data - sadayana damel saé. Skenario pangbasajanna: upami salah sahiji aplikasi wéb urang gagal, maka sadayana saderhana - aranjeunna dipareuman tina kasaimbangan.
Balancer (dina waktos éta éta Amazon urang elb) ditandaan mesin anu kaluar tina urutan sakumaha damang tur mareuman distribusi beban on aranjeunna. Amazon autoscaling digawé: nalika beban tumuwuh, mesin anyar ditambahkeun kana grup autoscaling, beban ieu disebarkeun ka mesin anyar - sagalana éta rupa. Kalayan pangimbang kami, logikana kira-kira sami: upami aya kajadian ka pangladén aplikasi, urang ngahapus pamundut ti dinya, buang mesin ieu, ngamimitian anu énggal sareng teraskeun damel. Skéma geus robah saeutik leuwih taun, tapi terus jalan: basajan, kaharti, sarta teu aya kasusah jeung eta.
Kami damel di sakumna dunya, puncak beban palanggan leres-leres béda, sareng, dina cara anu ramah, urang kedah tiasa ngalaksanakeun pagawéan jasa anu tangtu dina sagala komponén sistem kami iraha waé - teu diémutan ku para nasabah. Kituna, urang boga kasempetan pikeun mareuman database ti operasi, redistributing beban ka puseur data kadua.
Kumaha sadayana dianggo? - Kami ngalihkeun lalu lintas ka pusat data anu damel - upami aya kacilakaan di pusat data, teras lengkep, upami ieu mangrupikeun padamelan anu direncanakeun ku hiji pangkalan data, maka kami ngalihkeun bagian tina lalu lintas anu ngalayanan klien ieu ka pusat data kadua, ditunda. éta réplikasi. Lamun mesin anyar diperlukeun pikeun aplikasi wéb sabab beban dina puseur data kadua geus ngaronjat, aranjeunna bakal ngamimitian otomatis. Urang rengse pagawean, réplikasi dibalikeun, sarta kami balik sakabéh beban deui. Lamun urang kudu eunteung sababaraha karya dina DC kadua, contona, install apdet sistem atawa ngarobah setelan dina database kadua, lajeng, sacara umum, urang ngulang hal anu sarua, ngan dina arah séjén. Sareng upami ieu kacilakaan, maka urang ngalakukeun sadayana sacara sederhana: kami nganggo mékanisme panangan acara dina sistem ngawaskeun. Upami sababaraha cek dipicu sareng statusna kritis, teras urang ngajalankeun pawang ieu, pawang anu tiasa ngalaksanakeun logika ieu atanapi éta. Pikeun unggal database, urang tangtukeun server mana nu failover pikeun eta, jeung dimana lalulintas perlu switched lamun teu sadia. Dina sajarahna, kami nganggo nagios atanapi sababaraha garpu na dina hiji bentuk atanapi anu sanés. Sacara prinsip, mékanisme anu sami aya dina ampir sadaya sistem ngawaskeun; kami henteu nganggo anu langkung rumit acan, tapi sigana bakal aya. Ayeuna ngawaskeun dipicu ku henteu sayogi sareng gaduh kamampuan pikeun ngalihkeun hiji hal.
Dupi urang dicadangkeun sagalana?
Urang boga loba klien ti AS, loba klien ti Éropa, loba klien nu leuwih deukeut ka Wétan - Jepang, Singapura jeung saterusna. Tangtosna, pangsa ageung klien aya di Rusia. Hartina, gawé téh lain di hiji daérah. Pamaké hoyong réspon gancang, aya sarat pikeun sasuai jeung sagala rupa hukum lokal, sarta dina unggal wewengkon urang cagar dua puseur data, ditambah aya sababaraha layanan tambahan, nu, deui, merenah pikeun nempatkeun dina hiji wewengkon - pikeun klien anu di wewengkon ieu jalan. pawang REST, server otorisasina, aranjeunna kirang kritis pikeun operasi tina klien sakabéhna, anjeun tiasa pindah ngaliwatan aranjeunna kalayan reureuh ditarima leutik, tapi anjeun teu hoyong reinvent kabayang dina cara ngawas aranjeunna sarta naon anu kudu dipigawé. sareng maranehna. Ku alatan éta, urang nyobian nganggo solusi nu aya ka maksimum, tinimbang ngamekarkeun sababaraha jenis kompetensi dina produk tambahan. Sareng di mana waé kami nganggo saklar dina tingkat DNS, sareng kami nangtukeun liveliness jasa ku DNS anu sami. Amazon ngagaduhan jasa Rute 53, tapi sanés ngan ukur DNS dimana anjeun tiasa ngadamel éntri sareng éta-éta langkung fleksibel sareng merenah. Ngaliwatan eta anjeun bisa ngawangun jasa geo-disebarkeun kalawan geolocations, mun anjeun migunakeun eta pikeun nangtukeun mana klien datang ti na masihan anjeunna rékaman tangtu - kalayan bantuan na bisa ngawangun arsitéktur failover. Cék kaséhatan anu sami dikonpigurasi dina Rute 53 sorangan, anjeun nyetél titik-titik anu diawaskeun, nyetél métrik, nyetél mana protokol pikeun nangtukeun "liveness" jasa - tcp, http, HTTPS; Nyetél frékuénsi cék anu nangtukeun naha jasa éta hirup atanapi henteu. Sarta dina DNS sorangan anjeun tangtukeun naon bakal primér, naon bakal sekundér, dimana pindah lamun dipariksa kaséhatan dipicu di jero jalur 53. Sadaya ieu bisa dipigawé kalayan sababaraha parabot lianna, tapi naha éta merenah - urang nyetel eta. up sakali lajeng ulah mikir ngeunaan eta pisan kumaha urang ngalakukeun cék, kumaha urang pindah: sagalana jalan sorangan.
Nu kahiji "tapi": kumaha jeung naon cagar jalur 53 sorangan? Saha anu terang, kumaha upami aya kajadian ka anjeunna? Untungna, urang pernah stepped on rake ieu, tapi deui, kuring bakal boga carita dihareupeun naha urang ngira yén urang masih diperlukeun pikeun nyieun reservasi a. Di dieu urang nempatkeun jarami sateuacanna. Sababaraha kali sadinten urang ngabongkar sadaya zona anu aya dina jalur 53. API Amazon ngidinan Anjeun pikeun gampang ngirim aranjeunna dina JSON, sarta kami boga sababaraha server cadangan dimana urang ngarobah éta, unggah dina bentuk configs sarta boga, kasarna diomongkeun, konfigurasi cadangan. Upami aya kajadian, urang tiasa gancang nyebarkeun sacara manual tanpa kaleungitan data setélan DNS.
Kadua "tapi": Naon dina gambar ieu teu acan disimpen? The balancer sorangan! Distribusi klien kami dumasar daérah dilakukeun saderhana pisan. Kami ngagaduhan domain bitrix24.ru, bitrix24.com, .de - ayeuna aya 13 anu béda, anu beroperasi dina sababaraha zona. Urang datang ka handap: unggal wewengkon boga balancers sorangan. Hal ieu ngajadikeun eta leuwih merenah pikeun ngadistribusikaeun sakuliah wewengkon, gumantung kana dimana beban puncak dina jaringan. Upami ieu mangrupikeun kagagalan dina tingkat kasaimbangan tunggal, maka éta ngan saukur dicabut tina jasa sareng dipiceun tina dns. Upami aya sababaraha masalah sareng sakelompok balancers, teras aranjeunna dicadangkeun dina situs anu sanés, sareng ngagentos antara aranjeunna dilakukeun nganggo rute anu sami53, sabab kusabab TTL pondok, switching lumangsung dina maksimal 2, 3, 5 menit. .
Katilu "tapi": Naon anu teu acan dicadangkeun? S3, leres. Nalika kami nempatkeun file anu kami simpen pikeun pangguna dina s3, kami yakin yén éta ngajalin armor sareng teu kedah cagar nanaon di dinya. Tapi sajarah némbongkeun yén hal lumangsung béda. Sacara umum, Amazon ngajelaskeun S3 salaku layanan fundamental, sabab Amazon sorangan migunakeun S3 pikeun nyimpen gambar mesin, configs, gambar AMI, snapshots ... Jeung lamun s3 ngadat, sakumaha kajadian sakali salila 7 taun ieu, salami urang geus ngagunakeun. bitrix24, eta kieu eta kawas kipas a Aya sakabeh kebat hal anu datang nepi - henteu mampuh pikeun ngamimitian mesin virtual, gagalna api, jeung saterusna.
Sareng S3 tiasa turun - éta kajantenan sakali. Kituna, urang sumping ka skéma handap: sababaraha taun ka pengker aya euweuh fasilitas gudang objék publik serius di Rusia, sarta kami dianggap pilihan pikeun ngalakukeun hal urang sorangan ... Untungna, urang teu ngamimitian ngalakukeun ieu, sabab urang bakal geus ngali kana kaahlian nu urang teu boga kami boga, sarta meureun bakal mess up. Ayeuna Mail.ru gaduh panyimpenan anu cocog sareng s3, Yandex gaduh éta, sareng sajumlah panyadia sanés gaduh éta. Urang ahirna datang ka pamanggih yén urang hayang boga, firstly, cadangan, jeung Bréh, kamampuhan pikeun digawekeun ku salinan lokal. Pikeun wilayah Rusia sacara khusus, kami nganggo jasa Mail.ru Hotbox, anu cocog sareng API sareng s3. Kami henteu peryogi modifikasi utama pikeun kode di jero aplikasi, sareng kami ngadamel mékanisme di handap ieu: dina s3 aya pemicu anu memicu nyiptakeun / ngahapus objék, Amazon ngagaduhan jasa anu disebut Lambda - ieu mangrupikeun peluncuran kode tanpa server. nu bakal dieksekusi ngan lamun micu tangtu dipicu.
Kami ngalakukeun éta saderhana pisan: upami pemicu kami kahuruan, kami ngaéksekusi kode anu bakal nyalin obyék kana panyimpenan Mail.ru. Pikeun pinuh ngaluncurkeun karya sareng salinan data lokal, urang ogé peryogi sinkronisasi sabalikna supados klien anu aya di bagean Rusia tiasa damel sareng panyimpenan anu langkung caket ka aranjeunna. Surat badé ngabéréskeun pemicu dina panyimpenanna - éta bakal tiasa ngalaksanakeun sinkronisasi sabalikna dina tingkat infrastruktur, tapi ayeuna urang ngalakukeun ieu dina tingkat kode urang sorangan. Upami urang ningali yén klien parantos ngeposkeun file, teras dina tingkat kode urang nempatkeun acara dina antrian, ngolah sareng ngalakukeun réplikasi sabalikna. Naha éta goréng: lamun urang ngalakukeun sababaraha jenis karya jeung objék urang di luar produk urang, nyaeta, ku sababaraha cara éksternal, urang moal nyandak eta kana rekening. Kituna, urang antosan nepi ka ahir, nalika micu muncul dina tingkat gudang, ku kituna euweuh urusan dimana urang ngaéksekusi kode ti, obyék anu datang ka urang disalin ka arah séjén.
Dina tingkat kode, urang ngadaptar duanana gudang pikeun tiap klien: hiji dianggap utama, nu séjén dianggap cadangan. Upami sadayana henteu kunanaon, urang damel sareng gudang anu langkung caket ka kami: nyaéta, klien kami anu aya di Amazon, aranjeunna damel sareng S3, sareng anu damel di Rusia, aranjeunna damel sareng Hotbox. Upami bandéra dipicu, teras failover kedah dihubungkeun, sareng urang ngalihkeun klien ka panyimpenan anu sanés. Urang tiasa mariksa kotak ieu sacara mandiri dumasar wilayah sareng tiasa ngalihkeunana. Kami henteu acan nganggo ieu dina prakna, tapi kami parantos nyayogikeun mékanisme ieu sareng kami nyangka yén hiji dinten urang peryogi saklar ieu sareng tiasa dianggo. Ieu parantos kajantenan sakali.
Oh, sareng Amazon kabur ...
April ieu nandaan ulang taun awal Telegram meungpeuk di Rusia. Panyadia anu paling kapangaruhan anu tumiba dina kaayaan ieu nyaéta Amazon. Sareng, hanjakalna, perusahaan Rusia anu damel di sakumna dunya langkung sangsara.
Upami perusahaan global sareng Rusia mangrupikeun bagéan anu alit pisan, 3-5% - ogé, hiji cara atanapi anu sanés, anjeun tiasa ngorbankeunana.
Upami ieu mangrupikeun perusahaan murni Rusia - kuring yakin yén éta kedah ditempatkeun sacara lokal - saé, éta bakal gampang pikeun pangguna sorangan, nyaman, sareng bakal aya résiko anu langkung saeutik.
Kumaha upami ieu mangrupikeun perusahaan anu beroperasi sacara global sareng gaduh jumlah klien anu sami ti Rusia sareng dimana waé di sakumna dunya? Konektipitas ségmén penting, sareng aranjeunna kedah damel saling hiji atanapi anu sanés.
Dina ahir Maret 2018, Roskomnadzor ngirim surat ka operator panggedéna nyatakeun yén aranjeunna ngarencanakeun pikeun meungpeuk sababaraha juta IP Amazon pikeun meungpeuk ... utusan Zello. Hatur nuhun kana panyadia anu sami - aranjeunna suksés ngabocorkeun surat ka sadayana, sareng aya pamahaman yén sambungan sareng Amazon tiasa rusak. Dinten Jumaah, urang lumpat panik ka kolega urang ti servers.ru, nyarios: "Babaturan, urang peryogi sababaraha server anu bakal aya henteu di Rusia, sanés di Amazon, tapi, contona, dimana waé di Amsterdam," dina urutan. mun dina urutan bisa sahenteuna kumaha bae install VPN urang sorangan sarta proxy aya pikeun sababaraha titik tungtung nu urang teu bisa pangaruh sagala cara, contona endponts s3 sarua - urang moal bisa coba pikeun ngangkat layanan anyar jeung meunang ip béda, kami anjeun masih kedah dugi ka dinya. Dina ngan sababaraha poé, urang nyetél server ieu, meunang aranjeunna nepi na ngajalankeun, sarta, sacara umum, disiapkeun keur momen blocking dimimitian. Panasaran yén RKN, ningali kabingungan sareng panik, nyarios: "Henteu, kami moal ngahalangan naon waé ayeuna." (Tapi ieu persis dugi ka momen nalika Telegram mimiti diblokir.) Sanggeus nyetél kamampuhan bypass sarta nyadar yén meungpeuk nu teu acan diwanohkeun, urang, kumaha oge, teu ngawitan nyortir kaluar sakabeh masalah. Sumuhun, bisi wae.
Sareng ayeuna di 2019 urang masih hirup dina kaayaan meungpeuk. Kuring nempo tadi peuting: ngeunaan sajuta IP terus diblokir. Leres, Amazon ampir teu diblokir, dina puncakna ngahontal 20 juta alamat ... Sacara umum, kanyataanana tiasa waé teu aya kohérénsi, kohérénsi anu saé. Ngadadak. Bisa jadi teu aya alesan teknis - kahuruan, excavator, sagala rupa nu. Atawa, sakumaha urang geus katempo, teu sagemblengna teknis. Ku alatan éta, batur badag tur badag, kalawan ASs sorangan, meureun bisa ngatur ieu ku cara séjén - langsung nyambung jeung hal séjén geus di tingkat l2. Tapi dina vérsi anu saderhana, sapertos anu urang laksanakeun atanapi langkung alit, anjeun tiasa, upami bisi, gaduh redundansi dina tingkat server diangkat di tempat sanés, dikonpigurasi sateuacanna vpn, proxy, kalayan kamampuan gancang ngalihkeun konfigurasi ka aranjeunna dina éta. bagéan anu penting pikeun konektipitas anjeun. Ieu janten mangpaat pikeun urang langkung ti sakali, nalika pameungpeuk Amazon dimimitian; dina skenario anu paling parah, urang ngan ukur ngijinkeun lalu lintas S3 ngalangkungan aranjeunna, tapi laun-laun sadayana ieu direngsekeun.
Kumaha cagar ... hiji panyadia sakabéh?
Ayeuna kami henteu gaduh skénario upami sadayana Amazon turun. Kami gaduh skenario anu sami pikeun Rusia. Di Rusia, kami di-host ku hiji panyadia, ti mana kami milih sababaraha situs. Sareng sataun katukang urang nyanghareupan masalah: sanaos ieu dua pusat data, meureun aya masalah dina tingkat konfigurasi jaringan panyadia anu masih bakal mangaruhan duanana pusat data. Sarta kami bisa mungkas nepi sadia dina duanana situs. Tangtu éta kajadian. Urang réngsé nepi reconsidering arsitéktur jero. Éta henteu robih pisan, tapi pikeun Rusia ayeuna urang gaduh dua situs, anu sanés ti panyadia anu sami, tapi tina dua anu béda. Upami hiji gagal, urang tiasa ngalih ka anu sanés.
Hypothetically, pikeun Amazon kami tempo kamungkinan reservasi di tingkat panyadia sejen; meureun Google, meureun batur ... Tapi jadi jauh kami geus observasi dina praktekna yén bari Amazon boga kacilakaan di tingkat hiji zone kasadiaan, kacilakaan di tingkat hiji sakabéh wewengkon anu rada langka. Kituna, urang sacara téoritis boga pamanggih yén urang bisa nyieun hiji "Amazon teu Amazon" reservations, tapi dina praktekna ieu teu acan kasus.
Sababaraha kecap ngeunaan automation
Naha automation salawasna diperlukeun? Di dieu téh luyu pikeun ngelingan pangaruh Dunning-Kruger. Dina sumbu "x" nyaéta pangaweruh sareng pangalaman urang anu urang kéngingkeun, sareng dina sumbu "y" nyaéta kapercayaan kana tindakan urang. Mimitina urang terang nanaon sareng henteu yakin pisan. Teras we terang sakedik sareng janten yakin-mega - ieu anu disebut "puncak kabodoan", anu diilustrasi ku gambar "pikun sareng kawani". Teras urang parantos diajar sakedik sareng siap pikeun perang. Teras we lengkah dina sababaraha kasalahan mega-serius sarta manggihan diri di lebak asa, nalika urang sigana terang hiji hal, tapi dina kanyataanana urang teu nyaho loba. Teras, nalika urang nampi pangalaman, urang janten langkung percaya diri.
Logika urang ngeunaan sababaraha saklar otomatis pikeun kacilakaan tangtu dijelaskeun pisan ku grafik ieu. Kami ngamimitian - kami henteu terang kumaha ngalakukeun nanaon, ampir sadayana padamelan dilakukeun ku tangan. Teras we sadar yén urang tiasa ngagantelkeun otomatis kana sadayana sareng, sapertos, bobo kalayan damai. Sarta ujug-ujug urang lengkah dina mega-rake: a positif palsu dipicu, sarta kami pindah lalulintas deui mudik nalika, dina cara alus, urang teu kudu ngalakukeun ieu. Akibatna, réplikasi ngarecah atawa hal sejenna-ieu pisan lebak putus asa. Teras we dugi ka pamahaman yén urang kedah ngadeukeutan sadayana kalayan bijaksana. Hartina, asup akal pikeun ngandelkeun otomatisasi, nyayogikeun kamungkinan alarm palsu. Tapi! Upami akibatna tiasa ngabahayakeun, maka langkung saé nyerahkeun kana shift tugas, ka insinyur anu tugasna, anu bakal mastikeun sareng ngawas yén aya kacilakaan, sareng bakal ngalaksanakeun tindakan anu diperyogikeun sacara manual ...
kacindekan
Ngaliwatan kursus 7 taun, urang indit ti kanyataan yén lamun hal murag, aya panik-panik, nepi ka pamahaman yén masalah teu aya, aya ngan tugas, aranjeunna kedah - sarta bisa - direngsekeun. Nalika anjeun ngawangun jasa, tingali ti luhur, evaluasi sadaya résiko anu tiasa kajantenan. Upami anjeun ningali éta langsung, teras nyayogikeun pikeun redundansi sateuacanna sareng kamungkinan ngawangun infrastruktur anu teu toleran, sabab titik naon waé anu tiasa gagal sareng nyababkeun henteu tiasa dianggo jasa pasti bakal dilakukeun. Sareng upami sigana anjeun yén sababaraha unsur infrastruktur pasti moal gagal - sapertos s3 anu sami, tetep émut yén aranjeunna tiasa. Sareng sahenteuna dina téori, gaduh ide naon anu anjeun bakal laksanakeun sareng aranjeunna upami aya kajadian. Boga rencana manajemén résiko. Nalika anjeun mikir ngeunaan ngalakukeun sadayana sacara otomatis atanapi sacara manual, evaluasi résiko: naon anu bakal kajantenan upami otomatisasi mimiti ngagentos sadayana - naha ieu moal ngakibatkeun kaayaan anu langkung parah dibandingkeun kacilakaan? Panginten wae kedah nganggo kompromi anu lumayan antara panggunaan otomatis sareng réaksi insinyur dina tugas, anu bakal ngevaluasi gambaran nyata sareng ngartos naha aya anu kedah digentos dina tempat atanapi "enya, tapi henteu ayeuna."
A kompromi lumrah antara perfectionism jeung usaha nyata, waktu, duit nu bisa méakkeun dina skéma nu antukna anjeun bakal boga.
Téks ieu mangrupa versi diropéa sarta dimekarkeun tina laporan Alexander Demidov di konferensi .
sumber: www.habr.com