collaboration devops
как да декларирам масив от низове в Java
Сътрудничество в DevOps:
Малки стъпки на доставки в DevOps беше обяснено подробно в предишния ни урок.
Знаем, че ключовата мантра на DevOps е сътрудничеството и оттук идва и думата DevOps.
Прочетете => Задълбочени уроци за DevOps
Сътрудничеството е да се обединим като единен екип, за да се справим с всеки проблем в програмата, което пречи на фокусирането на клиентския фокус върху програмата и да ги реши, като ги притежава като свой собствен проблем възможно най-бързо, без никаква вина.
Сътрудничеството учи всички да говорят помежду си, да се срещат лице в лице, да се включват в своите срещи, дискусии, да си разбират задачите, зависимостта и да имат прозрачност в работата и да работят активно за предотвратяване на проблемите.
ВИДЕО Част 2 Блок 5: Сътрудничество - 15 минути 36 секунди
Стенограма:
Терминът колаборация се повтаря отново и отново в DevOps и мантрата Devops е колаборация. И така, нека разберем какво всъщност означава „сътрудничество“ в разработването на софтуер и контекста на DevOps.
Според мен, веднага щом организацията каже, ние внедряваме DevOps, автоматично мисленето за сътрудничество, което е свързано с практиката на девопс, започва в съзнанието на всички и ги прави по-фокусирани и внимателни към сътрудничеството и те започват да чувстват, че трябва да си сътрудничат . Това е магията на сътрудничеството.
Така че започването на сътрудничество с DevOps още в началото на проекта е много важно за организацията и екипа. Имам предвид екипа, членове на екипа на програмата.
Ще обясня няколко случая, когато съм виждал Dev да си сътрудничи с Ops, а ops да си сътрудничи с екипа на разработчиците, за да знаем какво всъщност означава сътрудничество в контекста на DevOps.
Това е представянето на инстанция едно.
Имаше случай, че имаше някакъв неизвестен проблем в инсталационния скрипт или скрипта за конфигуриране, че екипът на ops намираше предизвикателство при инсталирането на софтуера на определена настройка на клъстер в определена география.
Хвърляше някаква неизвестна грешка и беше чисто производствен проблем, който никога не се е появявал в среда на разработчици и оперативният екип наистина е похарчил много усилия, за да ги разреши сам, мислейки, че това е нещо, свързано с настройката, и те трябва да решат тя, която не се разреши доста дълго време.
Тогава незабавно екипът на Dev се качи, без дори да бъде поканен да помогне, въпреки че часовата зона беше различна, тя пое контрола над производствения обект, знаете, че обикновено достъпът до продукцията няма да бъде даден на всички, Ops просто споделя грешката подробности или друга информация, необходима на екипа за отстраняване на грешки.
Но тази ситуация е призована за предоставяне на достъп на един от членовете на разработчика, който всеотдайно прекара няколко часа в анализ на проблема на живо и осигури незабавна работа наоколо и следователно проблемът беше решен бързо.
Това е случаят на сътрудничеството, когато екипът на разработчиците доброволно е притежавал проблема и е помогнал на оперативния екип да го разреши. Това е чист пример за сътрудничество.
По същия начин, друг случай, позволете ми да покажа това схематично, което съм нарисувал. Друг случай е, че нещата са работили доста добре след надграждането на софтуера на определен сайт за няколко дни, внезапно работата на приложението започна да се забавя.
Крайните потребители започнаха да се сблъскват със сериозни транзакционни загуби поради това забавяне. Много обаждания за жалби започнаха да идват до представители на КСО, имам предвид, представители на обслужването на клиенти и те от своя страна започнаха да следят екипа по въпроса.
В този случай незабавно екипът на Dev и Ops се събраха и с информацията и подробностите за телеметрията, предоставени от екипа на Ops на екипа за разработчици, те можеха да отстранят проблема и да установят, че има някакъв проблем в аспекта на споделянето на товара и следователно представянето беше бавно.
И така, и двата екипа работиха заедно, за да отстранят проблема и да върнат нормалното в рамките на няколко часа. И така, както Dev, така и Ops заедно излязоха и си сътрудничиха заедно за решаването на проблема, вместо Dev да каже проблема си с Ops, а Ops да мисли, че това е проблем на Dev и екипът на разработчиците трябва да го разгледа и поправи.
Това е ясният пример за сътрудничество, при който всеки притежава проблемите, вместо да играе играта на вина, независимо чий е проблемът или губи време, за да разбере чий е проблемът, имайки предвид, че крайният потребител страда и проблемът се нуждае да се поправи скоро.
Така че, отново тук, проблемът не трябва да е само от производството, това може да бъде всеки прост вътрешен проблем за разработка на софтуер, толкова прост, колкото ежедневния проблем, или проблем с дизайна, или проблем с архитектурата, или дори прост проблем с инструмента.
Всеки проблем, свързан с програмата, или проблем, за който екипът знае, че причинява щети на клиента или забавя програмата, трябва да бъде собственост на всички, вместо да изолира проблема, че е проблем за разработка или проблем с операциите или проблем с тестване, и да допринесе за възможно най-бързото му разглеждане, е сътрудничество.
И така, сътрудничеството в контекста на DevOps е разработка и операции, които се обединяват и работят заедно за решаване на проблема възможно най-рано, като се има предвид фокусът на клиентите.
Сътрудничеството е както Dev, така и Ops, които притежават това, което се случва на живо, наблюдението и регистрирането и проверката на производителността са на върха, за да разрешат проблема, който се появява особено в производството в интерес на крайния потребител.
ИЛИ просто, мога да кажа, че целият екип, който работи постоянно заедно за решаване на проблема за постигане на целите на програмата, като се има предвид фокусът на клиентите, е сътрудничеството. Повтарям, постоянната съвместна работа за решаване на проблемите с цел постигане на програмните цели, като се има предвид вниманието на клиента, е сътрудничество.
Тогава възниква въпрос, как да развием това сътрудничество и кога трябва да инициираме сътрудничеството между екипа, който седи на километри един от друг ??
Очевидно е, че знаем, че както Dev, така и Ops не могат да локализират съвместно. Екипът на Ops трябва да е по-близо до работещия сайт или центровете за данни, а разработчикът трябва да е по-близо до центъра за разработване на софтуер. И така, как да постигнем постоянното сътрудничество между двата отбора ??
Първо, започването на сътрудничество с DevOps още в началото на проекта е много важно за организацията и екипа. Екипът, който имам предвид тук, е екипът на програмата.
Практикуването на няколко от следните неща би помогнало за преодоляване на пропастта между екипа и преодоляване на ограниченията на виртуалните екипи и помага за постигането на сътрудничеството.
Така че, нека видим кои са тези практики, които помагат за постигане на сътрудничество.
Включете развитието във всички съответни срещи и дискусии на оперативния екип и обратно.
Това не само ги обединява, но също така помага за разбирането на всяка от работните им области, ежедневните им проблеми и как работата им се отразява взаимно и кои са критичните неща, за които всеки трябва да се погрижи, за да избегне проблемите по-късно и следователно ги сближава и инициира удобна дискусия помежду си всеки път.
Преди въвеждането на практиката на DevOps, екипът на разработчиците никога не се е грижил за доставянето на софтуера на Operations. Знаете, че преди са били невежи или никога не са се занимавали с неща като инфраструктура, конфигурации, сървърни настройки, мрежови конфигурации, наблюдение на изпълненията на живо и т.н.,
Те мислеха, че всички тези дейности са отговорност на оперативния екип и разработчиците никога не са знаели за това. По-рано доставката за екип за разработка означаваше да бъде доставка само на екипа за операции, но с практиката DevOps доставката означава за производството, а не само за операциите.
По същия начин ops никога не са се грижили за кода, който разработващият екип разработва. Всеки проблем, с който се сблъскат по време на инсталацията на софтуера, функционалността или проблеми с производителността, те просто използваха, за да предадат парите на екипа за разработка и да ги помолят да го поправят и да го върнат.
Така че, познаването на работата на другия и разбирането на тяхната задача и притежаването на проблема помежду си през целия цикъл помага на екипа да разреши проблемите бързо.
Защото те знаят къде е проблемът и какво се случва в програмата и какво причинява проблема в производството и по този начин могат директно да отидат и да го отстранят без особени затруднения.
Така че сътрудничеството означава, че екипът за разработка трябва да разбере инфраструктурата и конфигурацията, а екипът за работа трябва да се притеснява за кода, качеството, доставката и сроковете.
Разбирането на зависимостта един от друг ще помогне за ускоряване на работата и извършването й навреме.
Както по време на инсталирането на софтуера, оперативният екип зависи от екип за разработка, за да разреши всички проблеми, свързани с инсталацията. По същия начин, докато кодирането на екипа за разработка зависи от много предварителни условия, които съществуват в живо, за да може оперативният екип да се грижи по време на процеса на кодиране.
Друг Пример е тестовият екип зависи от оперативния екип за предоставяне на примерни данни на живо от производството за тестване. Подробности за конфигурацията на околната среда, които да бъдат настроени в средата за разработка и т.н.
И така, и двата екипа трябва да си сътрудничат помежду си и да разберат зависимостта един от друг и да предоставят данните или информацията навреме, без да причиняват забавяне, като имат предвид фактора за часовата зона.
Поддържайте прозрачност, като възприемате практиките на DevOps като контрол на източника или контрол на версиите, което позволява на екипа да разбере всичко за програмата и помага за избягване на всякакви недоразумения.
И така, това основно поддържа прозрачността в екипа.
Не е необходимо членовете на екипа да зависят от какъвто и да е индивид или някаква конкретна информация, да каже, ако някой иска да знае конфигурацията, настроена на определен възел в клъстера, така че не е нужно да чакат оперативният екип да се събуди и предоставете им тези подробности, вместо това те могат да отидат в инструмента за контрол на версиите и да извлекат тази информация и да изпълнят задачата си без забавяне.
Ученето един от друг, особено от грешката на другите, е най-голямата характеристика на сътрудничеството. За да не повтарят вече тези грешки, направени от някой друг.
Така че, развитието се учи от операцията, а операциите се учат от разработката, било то нова технология, инструмент или да правите нещо по-опростен и по-добър начин. Където и двамата са на една и съща страница и следователно те си сътрудничат помежду си, като се учат един от друг.
Операциите винаги са имали чувството, че екипът на разработчиците е много бавен и те не могат да изпълняват навреме, сега, когато ежедневно взаимодействат с екипа за разработки, те разбират какво причинява закъснението, било то по-малко яснота в изисквания, проблем с дизайна, проблем с кодирането или друг проблем с инструмента.
Дори те се качват и предоставят своите ценни предложения за подобряване.
Също така, в случай на проблем или от производствения, или от сайта за разработка, DevOps въвежда култура на първо отстраняване на проблема, отколкото да се опитва да разбере кой или кой екип е въвел този проблем. И така всички се опитват да се съсредоточат върху отстраняването на проблема, вместо да губят време, за да разберат кой е причинил проблема.
Така че, Спрете да обвинявате и разглеждате всеки проблем като свой собствен и излезте напред, за да ги решите заедно и подкрепяйки проблема, подкрепяйки се по време на проблемите си, отново е сътрудничество.
Така че, мога да кажа, спрете да обвинявате играта, вината за игри отново е характеристика на сътрудничеството.
Когато всички започнат да мислят често в една и съща посока, един и същ начин на мислене и да работят върху едни и същи аспекти и практики, това отново е сътрудничество, както винаги, когато се разработва някаква нова функция, всеки мисли как да тества това, как да го разположи, как да следи това, е сътрудничество.
Така че, общото мислене в екипа е характеристика на сътрудничеството за пореден път.
Нека да си вземем почивка сега и да разберем малко повече за сътрудничеството в следващото ни видео.
PREV Урок | СЛЕДВАЩ Урок
Препоръчително четене
- Как да развием сътрудничество в екипите на DevOps
- Значение на малките увеличения на доставките в DevOps
- Непрекъсната интеграция в DevOps
- Непрекъснато внедряване в DevOps
- Непрекъсната доставка в DevOps
- DevOps Automation: Как се прилага автоматизацията в практиката на DevOps
- Урок за DevOps: Най-доброто ръководство за DevOps (25+ урока)
- Урок за тестване на DevOps: Как DevOps ще повлияе на QA тестването?