Hodie, Bitrix24 cultura centena gigabitarum negotiationis non habet, neque magnam ministrantium classem habet (quamvis, sane, admodum paucae sunt exsistentes). Sed apud multos clientes est principale instrumentum ad operandum in comitatu, verum est ad rem-criticam applicatio. Ergo nullo modo cadere potest. Quid si fragor evenit, sed servitium tam cito recuperatum est ut nemo aliquid animadverteret? Et quomodo fieri potest ut deficientem defectum efficiendi laboris qualitatem et numerum clientium? Alexander Demidov, moderator nubium officiorum apud Bitrix24, pro nostro blog locutus est quomodo systema reservationis evolvit per VII annos producti existentiae.
"Bitrix24 nos ante 7 annos Saas incessimus. Praecipua difficultas haec verisimiliter fuit: antequam publice in Saas emissa est, hoc productum simpliciter in forma solutionis cohibentis exstitit. Clientes eam a nobis emit, servientibus suis hosted, porta corporatum - solutionem generalem pro communicationis molestie, repositionis tabulariorum, administratione munerum, CRM, quae omnia sunt. Et per MMXII, constituimus ut SaaS mittere vellemus, nosmetipsos administrantes, tolerantiam et fidem praestandi culpam. Experientiam in via consecuti sumus, quia adhuc tunc simpliciter eam non habuimus, modo artifices programmantes eramus, non provisores servientes.
Cum deductis ad servitium, intelleximus rem potissimum curare culpam tolerantiae, constantiae et assiduitatis servitutis, quia si simplex ordinarius locus est, promptuarium, exempli gratia, cadit in te et ibi sedet. hora, modo pateris, imperia perdis, clientes amittis, sed pro ipso cliente tuo, hoc non est pro ipso discrimine. Conturbatus est, scilicet, sed abiit et emit illud in alio loco. Et si haec applicatio est, qua totum opus intra societatem, communicationem, decisiones ligatur, praecipua res est fidem utentium obtinere, id est ne deprimat neve cadat. Quia omne opus prohibere potest si aliquid intus non operatur.
Bitrix.24 ut SaaS
Primum prototypum ante annum publicum launches convocavimus, anno 2011 . Convenimus illud circiter octo, aspeximus, mirabamur, vel laborabat. Hoc est, formam ingredi posses, nomen portae ibi intrare, porta nova aperiret, et basis usoris crearetur. Inspeximus eam, aestimata in principio factum, abradendo, et per totum annum excolere perseuerauimus. Quia magnum negotium habuimus: duas bases codicis diversae facere noluimus, productum separatum sarcinatum, nubes solutiones separatas sustinere noluimus - omnia intra unum codicem facere voluimus.
Applicatio typica in eo tempore fuit unus ministrator in quo quidam PHP codicem currit, database mysql, fasciculi fasciculi, documenta, imagines in folder oneris ponuntur - bene, omnia opera. Eheu, impossibile est servitium telae criticae stabilis hac utens mittere. Cache distribuitur ibi non praebetur, replicatio datorum non praebetur.
Requisita proposuimus: haec facultas in diversis locis, subsidii replicationis collocanda est, et specimen in diversis locorum notitia centris distributa collocari. Logicam productum separa et re vera notitia repono. Vivificabiliter secundum onus scandere poterit, et staticas omnino tolerare. Ex his, revera, postulata producti emerserunt, quae per anni decursum purgavimus. Per hoc tempus in suggestu, quod ad unum, ad solutiones cohibendas, pro nostro servitio, evasit, ad ea quae nobis necessaria erant, adminiculum fecimus. Sustentationem mysql replicationis in plano ipsius producti: id est, elit, qui codicem scribit, non cogitat quomodo petitiones eius distribuantur, api nostris utitur, et scimus quomodo recte scribere et legere petitiones inter dominos distribuere. et mancipia.
Sustentationem fecimus in plano producto pro variis obiectorum nubecularum: google repositione, amazon s3, plus subsidii pro ACERVO aperto celeri. Hoc ergo opportunum fuit tam nobis pro servitio et pro machinis qui cum solutione sarcinarum laborant: si modo nostro API ad opus utantur, non cogitant de tabella finaliter ubi servabuntur, localiter in tabella systematis vel in the object file storage.
Quam ob rem statim decrevimus nos in planitie totius centri centrum reservare. In MMXII, totum in Amazon AWS deducimus quod hoc suggestu iam experti sumus - website nostrum ibi hospitatus est. Allecti sumus eo quod in unaquaque regione Amazonum plures zonas disponibilitates habet - etenim (in eorum terminologia) nonnulla centra data, quae ab invicem sunt plus minusve independentia, et nos permittunt reservare in plano centri integri; si subito deficit, databases dominus-magister replicantur, applicationes servientium interreti subnixi sunt, et notitia static ad s2012 objectum repositionis movetur. Onus libratum est eo tempore ab Amazone elb, sed paulo post ad nostrum onus libratores pervenimus, quia logica magis implicata opus erat.
Quid vellent, id acceperunt.
Omnia fundamentalia quae praestare voluimus - culpa tolerantia servientium, applicationum telae, databases - omnia bene operata sunt. Missionis simplicissimae: si una applicationes electronicae deficiunt, omnia simplicia sunt - ab aequilibrio sunt switched.
Librarius (tunc elb Amazonis erat) machinis notatis extra ordinem insalubris et oneris distributionem in eas avertit. Amazon autoscaling laboraverunt: cum onus crevisset, novae machinae globi autoscori adiectae sunt, onus novis machinis distributum est - omnia denique erant. Cum libratoribus nostris eadem fere ratio est: si quid acciderit applicationi servientis, postulationes ab eo removemus, has machinas eicimus, novas incipiunt et operantur. Ratio aliquantisper annos mutata est, sed pergit ad laborem: simplex est, intellegibilis, nullae difficultates cum ea sunt.
In toto orbe terrarum laboramus, culmina oneris emptoris sunt omnino diversa, et, amice, exsequi possimus in quibusvis partibus systematis nostri quovis tempore operae certae exercendae - a clientibus ignorantur. Occasionem ergo nobis datorum ab operando avertendi, sarcinam ad centrum secundum centrum redigendi.
Quomodo totum opus facit? - Negotiationem ad centrum datorum operantium commutandum - si casus ad centrum datorum, tunc omnino, si hoc nostrum consilium cum uno datorum opere, tum partem negotiationis serviendi clientibus istis ad centrum secundum suspendentes replicatio. Si novae machinae ad applicationes interretiales requiruntur, quia onus in secunda centri notitia auctum est, ipso facto incipient. Opus absolvimus, replicatio restituitur, et totum onus retro reddimus. Si opus aliquod in secundo DC considerare oportet, exempli gratia, systematis updates seu mutationem occasus in secundo datorum secundo instituimus, generaliter idem repetimus, modo in alteram partem. Quod si hoc est accidens, omnia leviter agimus: tracto-tracto mechanismo in magna ratione utimur. Si plures pressiones utitur et ad criticam statum accedit, hunc tractorem curritur, tracto qui hanc vel illam logicam exequi potest. Pro unoquoque datorum, designamus uter servienti defectionem pro eo sit, et ubi negotiatio mutari debet si unavailable. Historice utimur nagio vel aliquibus tricinis in una forma vel alia. In principio, similes machinae in quavis fere ratione vigilantia sunt, non utimur tamen aliqua complexione, sed fortasse aliquando volumus. Nunc magna vigilantia inexplicabilitas urget et facultatem ad aliquid mutandi habet.
Reliquimus omnia?
Multos clientes habemus ex USA, multos clientes ex Europa, multos clientes propinquiores ad Orientem - Iaponia, Singapore et cetera. Utique in Russia magna pars clientium sunt. Id est, labor non in una regione. Utentes celeri responsionis requiruntur, requiruntur variis legibus localibus obtemperandi, et in unaquaque regione duo centra data reservamus, et additamenta quaedam sunt officia, quae rursus opportuna sunt intra unam regionem - pro clientibus qui in eo sunt collocandi. Haec regio laborant. CETERA tracto, auctoritati servientes, minus criticae sunt ad operandum clientis in toto, potes per illas parva mora acceptissima commutare, sed rotam reinvenire non vis quam ut monitor illos et quid facias. cum illis. Conamur igitur solutionibus maximis exsistentibus uti, quam aliquas facultates in additis productis enucleare. Et alicubi in gradu DNS mutando trivialiter utimur, et eandem DNS vitam servitii decernimus. Amazon habet Route 53 servitium, sed non solum est DNS in quem viscus facere potes et id est — multo magis flexibile et commodum est. Per eam officia geolocationes cum geolocationibus distributa aedificare potes , cum eo uteris ut definias unde cliens venit et ei certas tabulas - cum eius auxilio architecturas deficientes aedificare potes . Eaedem reprehendo sanitatis in Route 53 se configurantur, terminos monitores pones, metricas pone, pone quae protocolla ad "vivitas" servitii determinandas - tcp, http, https; pone frequentia compescit, quae utrum religio viva sit necne. Et in ipso DNS exprimis quid primarium, quid secundarium, ubi ad commutandum si sanae perscriptio Urguet intra meatus 53. Hoc totum fieri potest cum quibusdam aliis instrumentis, sed cur opportunum sit - proponamus. semel et ne cogita omnino quomodo nos cohibet, quomodo mutamus: omnia per seipsam operatur.
Primum "sed"quomodo aut quo subsidio 53 ipsa? Quis scit, quid si acciderit? Fortunate, numquam in hac rastro stetimus, sed iterum narrabo praemissam habebo cur nos adhuc reservandum putemus facere. Hic nobis paleas posuimus in antecessum. Pluries in die facimus plenam exonerationem omnium zonarum quas habemus in itinere 53 . Amazon's API te facile permittit ut eas in JSON mitteret, et habemus plures tergum servientes ubi nos convertimus, eam in forma configs imposuisti et figuram tergum habere, aspere loquendo. Si aliquid acciderit, celeriter manuale illud explicari possumus sine notitia occasus DNS amissis.
secundus "sed"Quid in hac tabula nondum servatum est? librator ipsum! Distributio clientium in regione nostra simplicissima facta est. Ditiones bitrix24.ru, bitrix24.com, .de - nunc sunt 13 diversae, quae in variis zonis agunt. Ad sequentia venimus: unaquaeque regio libratores suos habet. Eo magis commodius est regiones per regiones distribuere, undecumque summum onus in retis est. Si hoc est defectus in libra unius libratoris, tunc simpliciter sumatur extra servitium et subtrahatur a dns. Si quaestio aliqua est cum librariorum globo, in aliis locis subnixi sunt, et inter eos commutatio fit eodem itinere 53, quia propter brevem TTL, commutatio intra maximum 2, 3, 5 minuta fit. .
Tertium "sed": Nondum quid servatur? S3, corrige. Cum tabellas collocavimus quas pro usoribus in s3 condimus, sincere credidimus esse armaturas transfigere et nihil ibi reservare. Sed aliter evenire res historia ostendit. In genere, Amazon munus fundamentale describit S3, quod Amazon ipsa S3 utitur ad machinas imagines, configs, AMI imagines, snapshots... Et si fragores s3, sicut semel per hos VII annos factum est, quamdiu usi fuimus. bitrix7, sequitur quasi ventilabrum Totus fasciculus rerum quae ascendunt – non posse incipere machinas virtuales, api defectum, et sic porro.
Et S3 cadere potest — Accidit semel. Itaque hoc schema devenimus: ante paucos annos nullae erant res publicae graves in Russia facultates repositae, et consideravimus optionem aliquid faciendi de nostro... Fortunate, hoc facere non coepimus, quia volumus. fodimus in peritia non habemus, et verisimiliter tatam. Nunc Mail.ru repositio s3 compatibilis habet, Yandex eam habet, et plures alii provisores eam habent. Tandem pervenit ad opinionem quam habere voluimus, primo, tergum, deinde, facultatem operari cum exemplaribus localibus. Pro regione Russiae specialiter utimur ministerio Mail.ru Hotbox, quod est API compatible cum s3. Maioribus modificationibus ad codicem intra applicationis non indigemus, et sequentes mechanismum fecimus: in s3 sunt triggers creationis/deletionis obiecti, Amazon servitium habet quod vocatur Lambda - hoc est signum servile immissi. quod mox futurum est, cum quaedam triggers utitur.
Id ipsum simpliciter fecimus: si ignes felis nostros, codicem exequimur qui obiectum Mail.ru repositionis imitabitur. Ut opus plene deducunt cum exemplaribus localibus notitiarum, etiam e contrario synchronisation egimus ut clientes qui in segmento Russico sunt cum repositione quae illis propinquior operari possit. Epistulae complendae sunt triggers in suo repositorio - poterit vicissim synchronisationem praestare in gradu infrastructura, sed hoc nunc agimus in nostro codice. Si clientem limam emissam esse videmus, in codice gradu eventum in queue ponimus, eo processum et replicationem reversam faciemus. Quare malum est: si in objectis nostris extra rem nostram, id est per aliqua externa media, aliquod opus agimus, rationem non habebimus. Exspectemus igitur usque ad finem, cum triggers apparent in gradu repono, ut ubicumque ex codice exercemus, id quod ad nos venit in alteram partem exscribatur.
In gradu codicis, utrumque schedulas in singulis clientibus subscribimus: una principale habetur, altera tergum unum consideratur. Si omnia bona sunt, cum repositione quae nobis propior est laboramus: id est, clientes nostri qui in Amazonibus sunt, laborant cum S3, et qui in Russia laborant, Hotbox laborant. Si vexillum utitur, debet connexi defectivum, et clientes in aliam tabulam commutare debemus. Capsam hanc independenter per regionem inspicere possumus et eas ultro citroque flectere possumus. Hoc in usu nondum usi sumus, sed hoc mechanismo providimus et putamus aliquando hoc ipso transitum egere et in manus venire. Hoc jam semel factum est.
Oh, et Amazon fugit...
Hoc Aprili signat anniversarium initium telegraphi interclusionis in Russia. Provisor affectissimus qui sub hoc cecidit Amazon est. Et proh dolor, societates Russiae quae pro toto mundo laboraverunt plura passi sunt.
Si societas globalis et Russia perexigua portio est, 3-5% — bene, modo vel alio, sacrificium facere potes.
Si haec societas mere Russiae est - pro certo habeo necessitatem localiter collocari - bene, simpliciter commodum erit ipsis utentibus commodis, et pauciores periculos erunt.
Quid, si haec societas quae globaliter operatur et circiter aequales numeros clientes habet ex Russia et alicubi circum orbem terrarum? Connectivity of the segments is important, and they work with each other way or another.
In fine mensis Martii 2018, Roskomnadzor litteras ad maximas operatores misit se affirmans pluries miliones IPS Amazonum intercludere ut impediret... Zello nuntio. Eisdem provisoribus gratias - litteras ad omnes feliciter emanarunt, et intellectus erat nexus cum Amazonibus discidere posse. Veneris dies erat, collegas nostros perculsi sumus a servientibus.ru, his verbis: "Amici, pluribus indigemus ministris qui non in Russia, non in Amazonibus, sed, exempli gratia, alicubi Amstelodami collocabuntur". ut VPN et procuratorem nostrum VPN aliqualiter instituere possimus ut aliquas ibi terminos influere non valeamus, exempli gratia terminos eiusdem s3 - novum ministerium erigere conari et aliam accipere non possumus. ip, nos etiamnum postulo illuc. Paucis diebus hos ministros constituimus, eos surreximus ac currendo, et generatim ad tempus interclusionem parari coepimus. Curiosus est RKN, fuss et terrorem spectans, dixit: "Minime, nihil nunc impediemus." (Sed hoc prorsus est usque ad tempus quo impediri Telegram coepimus.) Positis praeteritis facultatibus et interclusionem non esse introductam animadvertentes, nos tamen rem totam explicare non coepimus. Ita, modo in casu.
Et in 2019 adhuc vivimus condiciones interclusionis. Perspexi heri: circiter decies centena millia IPS pergunt impediri. Verum, Amazon paene omnino non impedita erat, ad 20 decies centena milia inscriptionum attigit. In genere, res est ne cohaerentia sit, bona cohaerentia. Subito. Existare non potest propter rationes technicas - incendia, excavatoria, omnia quae. Vel, ut vidimus, non omnino technicum. Ergo aliquis magnus et magnus, cum sua ASs, probabiliter hoc administrare potest aliis modis - connect directum et alia iam in gradu l2 sunt. Sed in versione simplici, sicut nostra vel etiam minora, potes, casu modo, redundantiam habere in plano servientium aliunde excitatorum, in antecessum vpn, procuratoris figuratum, cum facultate celeriter commutandi conformationem illis in segmentis illis. quae critica sunt pro connectivity tuam. Hoc nobis plus semel in promptu est, cum interclusio Amazonum incepit, in missione gravissima, modo per eas S3 negotiatio permissa est, sed sensim omnia dissoluta sunt.
Quam integram provisorem reservare...?
Nunc missionem non habemus in casu totius Amazonis descendentis. Similem missionem habemus pro Russia. In Russia hospitati fuimus ab uno provisore, ex quo plures sites habere voluimus. Et ante annum problema praebuimus: quamvis haec duo centra data sint, problemata iam possunt esse in plano provisoris retis, quae utraque notitia centra afficiet. Atque in utroque sites terminus sursum unavailable. Nempe id factum est. Nos finita architectura intus retractantes. Valde mutata non est, sed pro Russia habemus duas sites, quae non sunt ab eodem provisore, sed a duobus diversis. Si unum deficiat, ad alterum flectendum est.
Hypothetice, pro Amazon agimus possibilitatem reservationis in gradu alterius provisoris; fortasse Google, fortasse alius... Sed in praxi tantum observavimus quod, dum Amazonia accidentia in plano unius zonae disponibilitate habet, accidentia in plano totius regionis admodum rara sunt. Ideo theoretice ideam habemus ut reservationem "Amazon non Amazonum" faciamus, sed in praxi hoc nondum est.
Paucis verbis de automation
An automatio semper sit necessaria? Hic opportunum est effectum Dunning-Krüger memorare. In axe "x" est nostra cognitio et experientia quam obtinemus, et in axe "y" est fiducia in actionibus nostris. In primis nihil scimus, nec omnino certi sumus. Tunc cognoscimus pauca et mega-fiducia fieri - haec est, quae dicitur « apicem stultitiae», per imaginem « dementiae et fortitudinis illustratam ». Tunc pauca didicimus et parati sumus in pugnam ire. Tunc in aliquibus mega-gravioribus erratis ingredimur et in desperationis valle nos invenimus, cum aliquid scire videmur, sed re vera non multum novimus. Deinde, dum experimur, confidentiores fiimus.
Nostra logica de variis virgas latis certarum accidentium optime ex hoc grapho describit. Incepimus - nesciebamus quid agerem, omnia fere opera manu facta sunt. Tunc intelleximus nos automationem ad omnia apponere posse et quasi placide dormire. Subito in mega-rastro gradimur: positivus falsus utitur, et mercaturam ultro citroque mutamus cum, bono modo, hoc facere non debemus. Replicatio ergo frangit vel aliud quod est ipsa vallis desperationis. Et tunc ad intellectum veniendum est omnia sapienter accedere. Hoc est, sensui automation niti, falsis terroribus providendi possibilitatem. Sed! si consequentia vastare potest, satius est eam relinquere ad officium transferendi, ut fabrum in officio fungatur, qui cavebit et monitorem rem esse accidens, et actiones necessarias manualiter aget...
conclusio,
Per decursum 7 annorum processimus ex eo quod, cum aliquid cecidit, trepidatio est, ad intellectum quod problemata non existunt, tantum opus sunt, oportet - et possunt - solvi. Cum aedificas servitium, illud intuere superne, omnia pericula quae evenire aestiment. Si eos ilicet videris, tunc provide redundantiam in antecessum et possibilitatem aedificandi culpae substructionis tolerantis, quia quodlibet punctum, quod potest deficere, et inexpeditationem ministerii certum facere potest. Et licet tibi videatur aliqua elementa infrastructurae plane non deficere — sicut idem s3, tamen memorare possunt. Et quidem in ratione, ideam habes quid cum illis facias, si aliquid obtigerit. Habere consilium periculo procuratio. Cum cogitas omnia sponte vel manuale facere, pericula perpende: quid fiet si automatio omnia mutandi incipit - hocne in deteriorem condicionem casus comparati deducet? Forsitan alicubi necesse est uti compromissum rationabilem inter usum automationis et reactionem artificis in officio, qui veram imaginem aestimabit et intelligat num quid opus sit in loco mutandum vel "ita, sed non nunc".
Rationabilis compromissio inter perfectionismum et conatum realem, tempus, pecuniam quam in schemate quod tandem habebis potes expendere.
Hic locus est renovatus et amplificatus versionem relationis Alexandri Demidov in colloquio .
Source: www.habr.com