Nuper me DevOpsForum 2019 frequentavi, per Logrocon. In hoc colloquio participes solutiones et nova instrumenta invenire conati sunt ob mutuam rem et progressionem et technologiam informationes operarum specialium.
Colloquium successum fuit: vere multum utiles erant rumores, commoda propositio formata et multum communicatio cum oratoribus. Et maxime interest quod nemo aliquid mihi vendere temptavit, quod oratores in magnis colloquiis nuper commiserunt.
Excerptum ex orationibus Raiffeisenbank, Alfastrakhovanie, Mango Telecom experientiam in exsequendo automation et alia sub incisa.
Nomen meum Yana est, testor laboro, automationem facio, necnon DevOps, et amo ire ad colloquia et contiones. Praeteritis duobus annis in colloquiis Oleg Bunin fui (HighLoad++, TeamLead Conf), Iug eventus (Heisenbug, JPoint), TestCon Moscoviae, DevOps Pro Moscoviae, Big Data Moscuae.
Imprimis ad colloquium conferentiae admoneo. Minus exspecto quid erit de fama, et de oratore plura. Etiamsi fama evadit ut valde technologica et iucunda sit, non tamen potest aliquas optimas consuetudines ex relatione in tuo comitatu applicare. Et tunc oratori opus est.
Lux in fine pipeline ad Raiffeisenbank
Soleo oratores in discedere quod me intersit venor. In DevOpsForum 2019, disertus Raiffeisenbank, Mikhail Bizhan, usuram meam cepit. In oratione loquebatur quomodo iunctiones suas aduncum in DevOps paulatim comparant, cur opus sit, et quomodo ideam DevOps transmutationis ad negotiandum vendas. Bene, in genere, dixi quomodo lucem videam in fine pipeline.
Mikhail Bizhan, director automationis apud Raiffeisenbank
Nunc "DevOps" in societate sua non habent. Hoc est, operatur, sed non in omnibus. Cum DevOps exsequerentur, promptitudine iunctorum nituntur, tam secundum fabrum specialium, quam secundum necessitatem producti et maturitatem suggesti, in quo hoc opus fabricatur. Misha dixit quomodo negotium explicare DevOps opus sit.
Segmentum argentaria plures rectores incrementum habet: sumptus servitiorum et expansionem clientis basis. Augere sumptus officiorum non est ipsum bonum exactoris, sed augere basim clientem contrarium est. Si competitores obiective frigus productum dimittunt, omnes clientes ibi eunt, tunc temporis gradus mercatus sunt. Ideo novos fructus ad forum introducentes et celeritas introductio eorum est principale quod in ripis focus est. Hoc ipsum est DevOps, et negotia intelligere.
Proxima nota momenti: DevOps tempus ad nundinas non semper minuit. DevOps solus operari non potest, pars iusta est processus creandi et producendi productum ad forum ab evolutione ad productionem (ex codice ad emptorem). Sed omnia ante codicem ad DevOps non directe pertinentia. Hoc est, ipsum per annos mercatum studere possunt et totam vitam suam cum competitoribus capiendis degunt. Necesse est ut cito intelligat quid client opus sit ac instituere exsecutionem huius vel illius plumae - saepe hoc est quod non sufficit ad operandum DevOps et societatem ad finem suum assequendum. Itaque imprimis Raiffeisenbank negotium cum negotio constitit necessarium esse discere quomodo DevOps uteretur. Automatio propter automationem in pugna pro novis clientibus non multum adiuvabit.
In genere, Misha credit opus esse DevOps implendum, sed sapienter. Et paranda est quod in initio mutationis productivitas quadrigis stillabit, minus pecuniam merebitur, sed tunc iustificabitur.
Automatio temptationis apud Mango Telecom
Alia interesting relatio mihi pro teste data est ab Egor Maslov a Mango Telecom. Praesentatio dicta est "Automatio plenae probationis cycli in SCRUM quadrigis." Egor credit DevOps pro SCRUM specie creatum esse, sed simul, DevOps in SCRUM team introducens satis problematicum. Hoc accidit, quia SCRUM equos semper alicubi currit, tempus non est ab innovationibus distrahendum et processum reaedificandum. Problema etiam in eo consistit quod SCRUM non involvit separationem sub-iunctionum in bigas (tentans equos, progressionem theam, et sic porro). Praeterea, ad processum exsistentem automate, documenta necessaria sunt, et in SCRUM saepissime nulla prorsus documenta est - "factum maius est quam quaedam scripturae".
Post switch ad SCRUM, exploratores cum cristillis consulere coeperunt quomodo features experiendi. Paulatim volumen functionis auctum documentum non erat, et multum cimices capere coeperunt in functionibus quae per probationes non obductae erant et generatim non iam clarum erat qui illud probabat et quando. In nuce - confusio et vacillatio. Placuimus mutandae ad probationem automationem. Sed tunc erat defectus perfectus. Praecipuas automatarias automatarios conduxerunt qui in ACERVUS ignotas testium domorum inscripserunt. Instrumentum autotestorum laboravit, utique, sed postquam egressi sunt, per duas septimanas duravit. Proximum est conatus binarium numerum introducere autotesting. Initium est ab eo quod omnia intra societatem aedificanda sunt, tuo (vector dextro: peritia intus aedificanda), intra SCRUM compage, et documentum in processu crea. BIBLIOTHECA automation par acervus producti esse debet (hic illud addens, ne JavaScript consilium tuum cum aliquo alio probare). In fine concitus demom fecerunt quomodo autotest opera cum tota quadriga (utilia). Ita, concursus omnium membrorum manipulorum in processu automation auctus, necnon fiducia in autotests et casus quem hoc autotest definite adhiberi potest (nec in mense ob assiduis defectibus annotabitur).
Viam apud DevOpsForum 2019 microphonia aperta erat - longae notae et, mea quidem sententia, loquelarum forma utilis. Hoc in circuitu ambulas, audi relationes, et iudica in colloquio disputare aliquem locum vel problema dignum, experientiam communicans ad problema solvendum.
Animadvertit etiam me auctorum brevium rumores fecisse rivum. Quaelibet relatio non plus quam X minuta perstat, quae sequuntur. Hoc modo multa simul argumenta operire potes et ab oratoribus interrogare qui te curant.
Inter presentationes circum tabernas colloquii socii ambulavi et multam supellectilem quaesivi. Oh, indecorus amo!
Circum mensam et DevOps quaestiones cum directore evolutionis apud Alfastrakhovanie
Vico in DevOpsForum 2019 placenta mihi erat hora plenaria sessionis cum peritis DevOps. Quattuor participes sessionis invitati sunt ad videndum DevOps ex diversis angulis: Anton Isanin (Alfastrakhovanie, director evolutionis), Nailya Zamashkina (Fintech Lab, director operandi), Oleg Egorkin (Rostelecom, raeda Agile) et Anton Martyanov (peritus independens, in DevOps spectavit. negotium ex parte).
Periti propius ad populum sederunt ac deinde res fieri inceperunt: integram horam participes ab auditoribus interrogaverunt, et periti rapuerunt. Aliquando verae disputationes erant. Interrogationes valde diversae erant, exempli gratia: sunt DevOps fabrum omnino necessarii, cur exerceri non possunt ut administratores systematis, si DevOps omnibus exhibeatur, quid valeat, et sic porro.
Deinde cum Antonio Isanin personaliter locutus sum. De necessitate culturae DevOps ad omnem domum deducendi sumus et obscuram partem DevOporum transformationis patefecit.
Fingamus omnes simul convenisse et statuisse DevOps tam facto et negotio et manipulo opus esse. Eamus effectum. Omnia elaborata. exhalavimus. DevOps propius ad clientem nos attulit, nunc omnia vota sua celeriter implere possumus. Quam ob rem magnam Opis partem habemus cum strictis normis et requisitis, et constanter invenit in facto defectus et postulationum fasciculum gignit. Praeterea omnes defectus status "urgente" assignantur, etiam si cliens insperato loco viridis globulum flavum colorare voluisset. Crescit consilium, numerus remissionum crescit ac proinde numerus defectuum et errorum novarum functionum per clientes. Opis plus conducit 10 ut cum defectibus referat, et progressus 15 plus conducat ad clausuras custodiendas. Et loco novas notas introducendi, manipulus opera SD cum infinitis laborat, explicans functionem usoris simul ac sustentationem. Quam ob rem et Opis et progressus laborant, sed client et res infelices sunt: nova lineamenta haerere. Evenit ut DevOps esse videatur, sed non videtur esse.
De necessitate deducendi DevOps, Antonius diserte affirmavit hoc directe pendere a magnitudine negotii. Si clientem unum annum serviens centena milia milium deducit, DevOps non opus est (dummodo non opus sit novas huic clienti regulariter evolvendas mutationes). Scelerisque omne tegitur. Sed si res crescit et magis clientes apparent, parere debes. Pro regula non est frigus Opis in comitatu initio. Primum incidimus factum, et tunc solum intelligimus quod in ordine operis ad opus faciendum est, ut observare debeamus oculis in servientibus et monitoris commeatus. Id cum Ope existit. Reliquum est ut Opem, ut divisio separatum, fasciculum obex evolutionis inceperit et omnes deliberationes stabulare incipiant. Hoc est, hoc casu, culturae DevOps iam ad rem pertinet, sed oblivisci non debemus de latere caliginoso.
Source: www.habr.com