Мени

Сарадња у ДевОпс-у

collaboration devops

Испробајте Наш Инструмент За Елиминисање Проблема

Сарадња у ДевОпс-у:

Мали кораци испорука у ДевОпс-у је детаљно објашњено у нашем претходном водичу.

Знамо да је кључна мантра ДевОпс-а сарадња и отуд је стигла реч ДевОпс.

Прочитајте => Дубински водичи за ДевОпс

Сарадња треба да се удружи као јединствени тим за решавање било ког проблема у програму, што кочи фокусирање корисника на голманство у програму и решава их тако што ће их поседовати као свој проблем што је брже могуће, без икакве кривице.

Сарадња у ДевОпс-у

Сарадња учи све да разговарају једни с другима, да се сретну лицем у лице, да се укључују у своје састанке, дискусије, разумеју задатке, зависност и транспарентност у раду и раде проактивно на спречавању проблема.

ВИДЕО Део 2, блок 5: Сарадња - 15 минута 36 секунди

Препис:

Израз сарадња се понавља и понавља у ДевОпс-у, а Девопс мантра је сарадња. Дакле, хајде да схватимо шта „сарадња“ заиста значи у развоју софтвера и ДевОпс контексту.

По мени, чим организација каже, примењујемо ДевОпс, аутоматски размишљање о сарадњи повезано са праксом девопса започиње у свима и чини их фокусиранијима и пажљивијима према сарадњи и почињу да осећају да морају сарађивати . То је магија сарадње.

Дакле, покретање ДевОпс сарадње од самог почетка пројекта је веома битно за организацију и тим. Мислим на тим, на чланове програма.

Објаснићу неколико случајева када сам видео Дев-а како сарађује са Опс-ом, а опс-ове са развојним тимом, тако да ћемо знати шта заправо сарадња значи у контексту ДевОпс-а.

Ово је приказ инстанце један.

Било је случајева да је у скрипти за инсталацију или скрипти за конфигурацију постојао неки непознати проблем који је опс тим пронашао изазов у ​​инсталирању софтвера на одређено подешавање кластера у одређеној географији.

Добацивало је неку непознату грешку и представљао је чисти производни проблем, који се никада није догодио у развојном окружењу, а оперативни тим је заиста потрошио пуно напора да их реши сам мислећи да је то нешто повезано са намештањем и да то треба решити то, које се није решило прилично дуго.

Тада се Дев тим одмах огласио, а да није ни позван да помогне, иако је временска зона била другачија, преузела је контролу над производним местом, знате да генерално приступ производњи неће бити доступан свима, Опс само дели грешку детаље или било које друге информације које су тиму потребне за отклањање грешака.

Али ова ситуација је потребна за омогућавање приступа једном од чланова развојног тима, који је предано провео неколико сати у анализирању проблема уживо и обезбедио непосредан посао око тога, па је проблем брзо решен.

Ово је пример сарадње када је развојни тим добровољно поседовао проблем и помогао оперативном тиму да га реши. Ово је чиста инстанца сарадње.

плскл питања и одговори за интервју пдф

Слично томе, још један пример, дозволите ми да то схематски прикажем, а који сам нацртао. Друга инстанца је да су ствари неколико дана радиле прилично добро након надоградње софтвера на одређеној локацији, одједном су перформансе апликације почеле да се успоравају.

Крајњи корисници су се суочили са великим трансакционим губицима због овог успоравања. Много позива за притужбе почело је да стиже представницима ЦСР-а, мислим, представницима корисничке службе, а они су заузврат почели да прате тим по том питању.

У овом случају, одмах су се окупили и Дев и Опс тим, а са информацијама и телеметријским детаљима које је Опс тим пружио развојном тиму, могли су да отклоне проблем и утврде да постоји неки проблем у аспекту поделе оптерећења и стога су перформансе биле споре.

Дакле, оба тима су заједно радила на решавању проблема и враћању у нормалу у року од неколико сати. Дакле, овде су се и Дев и Опс заједно јавили и заједно сарађивали на решавању проблема уместо да је Дев рекао свој проблем Опс, а Опс мислећи да је то Дев-ов проблем и да га мора развити и поправити тим за развој.

Ово је јасна инстанца сарадње у којој су сви власници проблема, уместо да се играју кривице, без обзира чији је проблем или троше време на откривање чијег је проблема, имајући на уму да крајњи корисник пати и да проблем треба да се ускоро поправи.

Дакле, опет овде, проблем не мора бити само из производње, то може бити било које једноставно интерно питање развоја софтвера, једноставно као свакодневни проблем, проблем дизајна или архитектуре, или чак једноставан питање алата.

Било који проблем повезан са програмом или било који проблем за који тим зна да наноси штету купцу или успорава програм, мора бити у власништву свих, уместо да изолује проблем у вези са развојним проблемом или оперативним проблемом или проблемом тестирања, и допринети да се то што пре реши, је сарадња.

Дакле, сарадња у контексту ДевОпс-а је развој и операције које се удружују и раде заједно на решавању проблема што је раније могуће, имајући на уму фокус на купцу.

Сарадња је и Дев и Опс у власништву над оним што се дешава уживо, надгледање и евидентирање и провера перформанси су на врху како би решили проблем који се посебно јавља у производњи у интересу крајњег корисника.

ИЛИ једноставно, могу да кажем да је целокупни тим, који непрестано раде заједно на решавању проблема ради постизања програмских циљева, имајући у виду фокус корисника, сарадња. Понављам, непрекидан заједнички рад на решавању проблема како би се постигли програмски циљеви имајући на уму фокус корисника је сарадња.

Тада се поставља питање, како да развијемо ову сарадњу и када треба да започнемо сарадњу између тима који седи миљама далеко један од другог ??

Очигледно је да знамо да и Дев и Опс не могу колоцирати. Опс тим треба да буде ближи радном месту или центрима података, а програмер треба да буде ближе центру за развој софтвера. Па, како постићи сталну сарадњу између оба тима ??

Пре свега, покретање ДевОпс сарадње од самог почетка пројекта је веома битно за организацију и тим. Тим на кога мислим овде су чланови тима програма.

Вежбање неколико следећих ствари помогло би у премошћавању јаза између тима и превазилажењу ограничења виртуелних тимова и помогло у постизању сарадње.

Па, да видимо које су то праксе које помажу у постизању сарадње.

Укључите развој у све релевантне састанке и дискусије Оперативног тима и обрнуто.

То их не само окупља, већ помаже и у разумевању сваког њиховог радног подручја, свакодневних проблема и како њихов рад утиче један на другог и које су критичне ствари о којима би свако требало да се побрине да би касније избегао проблеме и стога их приближава и сваки пут покреће угодну међусобну дискусију.

Пре увођења праксе ДевОпс, тим за развој никада није марио за испоруку софтвера Операцијама. Знате да су некад били неуки или да се никада нису бринули око ствари попут инфраструктуре, конфигурација, подешавања сервера, мрежних конфигурација, праћења перформанси уживо итд.,

Некада су мислили да су све ове активности у надлежности Оперативног тима, а развојни тим никада није знао за то. Раније је испорука за развојни тим значила да буде испорука само оперативном тиму, али са праксом ДевОпс, испорука значи производњи, а не само операцијама.

Слично томе, оперативни систем никада није марио за код који је развојни тим производио. Било који проблем са којим се суоче током инсталације софтвера, функционалности или проблема са перформансама у производњи, једноставно су пребацивали новац развојном тиму и тражили да га поправе и врате.

Знање међусобног рада и разумевање њиховог задатка и поседовање међусобних проблема током циклуса помаже тиму да брзо реши проблеме.

Јер они знају где је проблем и шта се дешава у програму и шта узрокује проблем у производњи, па стога могу без проблема да га реше и реше.

Дакле, сарадња значи да развојни тим треба да разуме инфраструктуру и конфигурацију, а оперативни тим да се брине око кода, квалитета, испоруке и рокова.

Разумевање међусобне зависности помоћи ће убрзавању посла и испоруци на време.

Као и током инсталације софтвера, оперативни тим зависи од развојног тима да би решио све проблеме у вези са инсталацијом. Слично томе, док кодирање развојног тима зависи од пуно предуслова који постоје у уживо да би оперативни тим обезбедио бригу током процеса кодирања.

Други Пример је тест тим зависи од оперативног тима да пружи узорке података уживо из производње за тестирање. Детаљи конфигурације окружења који се постављају у развојном окружењу итд.

Дакле, оба тима морају међусобно сарађивати и разумети међусобну зависност и пружити податке или информације на време без изазивања одлагања имајући у виду фактор временске зоне.

Одржавајте транспарентност усвајањем ДевОпс пракси попут контроле извора или контроле верзија која омогућава тиму да разуме све о програму и помаже у избегавању неспоразума.

Дакле, ово у основи одржава транспарентност унутар тима.

Чланови тима не морају да зависе од било ког појединца или било које одређене информације, рецимо ако неко жели да зна конфигурацију постављену на одређеном чвору кластера, тако да не треба да чекају да се оперативни тим пробуди и пружите им ове детаље, радије могу да оду до алата за контролу верзија и преузму ове информације и могу да изврше свој задатак без одлагања.

Учење једних од других, посебно на грешкама других, највеће су карактеристике сарадње. Да не би већ поновили ове грешке које је починио неко други.

Дакле, развој се учи из рада, а операције се учи из развоја, било да је то нова технологија, алат или нешто што се ради на једноставнији и бољи начин. Где су обојица на истој страници и стога сарађују једни с другима учећи једни од других.

Операције су увек имале осећај да је развојни тим веома спор и да не могу да изврше испоруку на време, сада када свакодневно комуницирају са развојним тимом, разумеју шта узрокује кашњење, било мање јасноће у захтеви, проблем дизајна, проблем кодирања или било који други проблем са алатом.

Чак се и они упуштају и дају своје драгоцене предлоге за побољшање.

Такође, у случају било ког проблема било са производне или са развојне локације, ДевОпс уводи културу првог решавања проблема него покушаја да сазна ко је или који тим увео овај проблем. И тако се сви покушавају усредсредити на решавање проблема, а не на губљење времена на откривање ко је проблем проузроковао.

Дакле, престаните да окривљујете и сматрате сваки проблем својим, и јавите се да их заједно решите и подржите проблем, подржавајући једни друге током њихових проблема поново је сарадња.

Дакле, могу да кажем, престаните да кривите игру, играње кривица је карактеристика сарадње још једном.

Када сви почну заједнички размишљати у истом правцу, исти начин размишљања и радити на истим аспектима и праксама, опет је сарадња, као кад год се развије нека нова функција, сви размишљају како то тестирати, како то применити, како надгледати, је сарадња.

Дакле, заједничко размишљање унутар тима је карактеристика поновне сарадње.

Направимо сада паузу и мало више о сарадњи ћемо разумети у нашем следећем видеу.

ПРЕВ Туториал |. | СЛЕДЕЋА Лекција

Препоручено читање

^