Меню

Співпраця в DevOps

collaboration devops

Спробуйте Наш Інструмент Для Усунення Проблем

Співпраця в DevOps:

Невеликий приріст поставок у DevOps було детально пояснено в нашому попередньому навчальному посібнику.

Ми знаємо, що ключовою мантрою DevOps є співпраця, а отже, і з’явилось слово DevOps.

Прочитати => Поглиблені підручники DevOps

Співпраця полягає в тому, щоб об’єднатись єдиною командою для вирішення будь-якої проблеми в програмі, що заважає зосереджуванню уваги клієнтів на програмі та вирішувати їх, володіючи ними як власною проблемою якомога швидше, без будь-якої звинувачувальної гри.

Співпраця в DevOps

Співпраця вчить усіх розмовляти один з одним, зустрічатися один з одним віч-на-віч, залучати один одного до своїх зустрічей, дискусій, розуміти завдання одне одного, залежність і мати прозорість у роботі та активно працювати над попередженням проблем.

ВІДЕО Частина 2 Блок 5: Співпраця - 15 хвилин 36 секунд

Стенограма:

зразки тестових кейсів для ручного тестування

Термін співпраця повторюється знову і знову у DevOps, а мантра Devops - це співпраця. Отже, давайте зрозуміємо, що насправді означає «співпраця» у розробці програмного забезпечення та контексті DevOps.

На мою думку, як тільки організація заявляє, що ми впроваджуємо DevOps, мислення про співпрацю, яке пов’язане з практикою девопсу, автоматично починається у свідомості кожного і робить їх більш зосередженими та пильними до співпраці, і вони починають відчувати, що їм потрібно співпрацювати . Це магія співпраці.

Отже, ініціювати співпрацю з DevOps з самого початку проекту дуже важливо для організації та команди. Я маю на увазі команду, учасників програми.

Я збираюся пояснити кілька випадків, коли я бачив, як Dev співпрацює з Ops, а ops - з командою розробників, щоб ми знали, що насправді означає спільна робота в контексті DevOps.

Це подання екземпляру один.

Був випадок, що в сценарії інсталяції або сценарії конфігурації була якась невідома проблема, через яку команда OPS знаходила проблему при встановленні програмного забезпечення на певній установці кластера в певній географії.

Це було викиданням якоїсь невідомої помилки і була чистою виробничою проблемою, яка ніколи не траплялась у середовищі розробника, і операційна команда дійсно витратила багато зусиль на їх вирішення, думаючи, що це щось пов’язане з налаштованим, і їм потрібно вирішити це, яке не вирішилось досить довго.

Тоді відразу команда розробників завітала, навіть не запросивши допомогти, хоча часовий пояс був іншим, він взяв контроль над виробничим майданчиком, ви знаєте, загалом доступ до виробництва буде надаватися не всім, Ops просто ділиться помилкою деталі або будь-яка інша інформація, необхідна команді для налагодження.

Але ця ситуація вимагає надання доступу одному з членів команди розробників, який віддано витратив кілька годин на аналіз проблеми в прямому ефірі та забезпечив негайну роботу, і, отже, проблема була швидко вирішена.

Це приклад співпраці, коли команда розробників добровільно володіла проблемою та допомагала команді операторів її вирішити. Це чистий приклад співпраці.

Подібним чином, інший приклад, дозвольте мені показати це схематично, яке я намалював. Інший приклад полягає в тому, що після оновлення програмного забезпечення на певному сайті протягом декількох днів справи працювали досить добре, і раптом продуктивність програми почала сповільнюватися.

Кінцеві користувачі почали стикатися з серйозними трансакційними втратами через це уповільнення. Багато заявок на скарги почали надходити до представників КСВ, я маю на увазі представників служби обслуговування клієнтів, і вони, в свою чергу, почали стежити за командою з цього питання.

У цьому випадку миттєво зібралися як команда розробників, так і інформація та дані телеметрії, надані командою розробників команді розробників, вони могли налагодити проблему та визначити, що є певна проблема в аспекті розподілу навантаження та отже, продуктивність була повільною.

Отже, обидві команди працювали разом, щоб вирішити проблему та повернути нормальний стан протягом декількох годин. Отже, тут і Dev, і Ops разом виступили і спільно працювали над вирішенням проблеми, замість того, щоб Dev говорив про свою проблему Ops, а Ops думав, що це проблема Dev, і команда розробників повинна її розглянути та виправити.

Це чіткий приклад співпраці, коли кожен володіє проблемами, замість того, щоб грати у гру вини, незалежно від того, чия проблема це, або витрачати час на з’ясування, чия проблема, маючи на увазі, що кінцевий користувач страждає і проблема потребує буде виправлено найближчим часом.

Отож, знову ж таки, проблема не повинна полягати лише у виробництві, це може бути будь-яка проста внутрішня проблема розробки програмного забезпечення, така проста, як повсякденна проблема, або проблема дизайну, або проблема архітектури, або навіть проста інструмент питання.

Будь-яка проблема, пов’язана з програмою, або будь-яка проблема, про яку команда знає, що завдає шкоди замовнику або уповільнює програму, має належати всім, замість того, щоб ізолювати проблему, що це проблема розробки, проблема роботи або проблема тестування, і сприяти якнайшвидшому вирішенню цього питання - це співпраця.

Отже, співпраця в контексті DevOps - це розробка та об'єднання операцій та спільна робота над вирішенням проблеми якомога раніше, маючи на увазі увагу клієнта.

Співпраця - це як Dev, так і Ops, що володіють тим, що відбувається в прямому ефірі, моніторинг та реєстрація, а також перевірка продуктивності - це головне, щоб вирішити проблему, яка виникає, особливо у виробництві, в інтересах кінцевого користувача.

АБО просто, я можу сказати, що вся команда, яка постійно працює разом для вирішення проблеми для досягнення цілей програми, маючи на увазі увагу клієнтів, - це співпраця. Повторюю, постійно спільна робота над вирішенням проблем для досягнення цілей програми, маючи на увазі клієнта, - це співпраця.

Тоді виникає запитання, як нам розвивати цю співпрацю і коли нам потрібно ініціювати співпрацю між командою, яка сидить за милі одне від одного ??

Очевидно, ми знаємо, що і Dev, і Ops не можуть спільно знаходити місце. Команда Ops повинна бути ближче до робочого сайту або центрів обробки даних, а розробник повинен бути ближче до центру розробки програмного забезпечення. Отже, як нам досягти постійної співпраці між обома командами ??

Перш за все, ініціювати співпрацю з DevOps з самого початку проекту дуже важливо для організації та команди. Я маю на увазі тут команду, яка є учасниками програми.

Практика кількох наступних речей допомогла б подолати розрив між командою та подолати обмеження віртуальних команд, а також допомогла досягти співпраці.

Отже, давайте подивимось, які саме практики допомагають досягти співпраці.

Залучайте Розвиток до всіх відповідних зустрічей та обговорень Оперативної групи та навпаки.

Це не тільки об’єднує їх, але й допомагає зрозуміти кожну з їх робочих областей, їхні повсякденні проблеми та те, як їх робота впливає одна на одну, і які найважливіші речі слід подбати кожному, щоб уникнути проблем пізніше та отже, зближує їх і щоразу ініціює комфортну дискусію між собою.

До запровадження практики DevOps команда розробників ніколи не дбала про те, щоб доставити програмне забезпечення до Operations. Ви знаєте, що вони раніше були необізнаними або ніколи не турбувались про такі речі, як інфраструктура, конфігурації, налаштування серверів, конфігурації мережі, моніторинг виступу в реальному часі тощо,

Раніше вони думали, що всі ці заходи відповідають за оперативну команду, і команда розробників ніколи не знала про це. Раніше доставка для команди розробників означала доставку лише команді операцій, але за практикою DevOps, доставка кошти до виробництва, а не лише до операцій.

програмне забезпечення для завантаження відео з

Подібним чином, операційні системи ніколи не дбали про код, який розробляла команда розробників. Будь-які проблеми, з якими вони стикаються під час встановлення програмного забезпечення, функціональних можливостей або проблем із продуктивністю, вони просто передавали гроші команді розробників та просили їх виправити та повернути.

Отже, знання роботи одне одного та розуміння їх завдання та володіння проблемою одне одного протягом циклу допомагає команді швидко вирішити проблеми.

Тому що вони знають, в чому проблема, і що відбувається в програмі, і що спричиняє проблему у виробництві, і, отже, можуть безпосередньо піти та виправити це без особливих труднощів.

Отже, співпраця означає, що команда розробників повинна розуміти інфраструктуру та конфігурацію, а команда операцій повинна турбуватися про код, якість, доставку та терміни.

Розуміння залежності один від одного допоможе пришвидшити роботу та виконати її вчасно.

Як і під час інсталяції програмного забезпечення, операційна група залежить від команди розробників, щоб вирішити будь-які проблеми, пов'язані з інсталяцією. Подібним чином, під час кодування команда розробників залежить від безлічі передумов, які існують в реальному часі, щоб операційна команда забезпечувала турботу під час процесу кодування.

Інший Приклад Це тестова група залежить від операційної групи, щоб надати зразки реальних даних з виробництва для тестування. Деталі конфігурації середовища, які слід налаштувати в середовищі розробки тощо.

Отже, обидві команди повинні співпрацювати між собою та розуміти залежність одна від одної та надавати дані чи інформацію вчасно, не викликаючи жодних затримок, маючи на увазі фактор часового поясу.

Підтримуйте прозорість, застосовуючи практики DevOps, такі як контроль джерел або контроль версій, що дозволяє команді розуміти все про програму та допомагає уникнути будь-яких непорозумінь.

Отже, це в основному підтримка прозорості в команді.

Членам команди не потрібно залежати від будь-якої особи чи будь-якої конкретної інформації, якщо хтось хоче знати конфігурацію, налаштовану на певному вузлі кластера, тому їм не потрібно чекати, поки операційна команда прокинеться і надайте їм ці деталі, скоріше вони можуть перейти до інструменту контролю версій і отримати цю інформацію і можуть виконати своє завдання без будь-яких затримок.

Навчання один у одного, особливо на помилках інших, є найбільшими характеристиками співпраці. Щоб вони вже не повторювали цих помилок, скоєних кимось іншим.

Отже, розвиток - це вчитися на операції, а операції - це вчитися на розробці, будь то нова технологія, інструмент або щось простіше та якісніше. Де вони обидва знаходяться на одній сторінці і, отже, вони співпрацюють між собою, навчаючись один у одного.

Операції завжди звикли думати, що команда розробників працює дуже повільно і вони не можуть виконувати завдання вчасно, тепер, коли вони щодня взаємодіють з командою розробників, вони розуміють, що спричиняє затримку, будь то менша чіткість у вимоги, проблема дизайну, проблема кодування або будь-яка інша проблема інструменту.

Навіть вони пропонують свої цінні пропозиції щодо вдосконалення.

найкращий безкоштовний конвертер mkv в dvd -

Крім того, у разі виникнення будь-яких проблем із виробничої або з веб-сторінки розробки, DevOps запроваджує культуру першого усунення проблеми, ніж намагання з’ясувати, хто або яка команда представила цю проблему. І тому всі намагаються зосередитись на вирішенні проблеми, а не витрачати час на з’ясування того, хто її спричинив.

Отже, припиніть звинувачувати та розглядати кожну проблему як свою власну, і виступайте, щоб вирішити їх разом та підтримуючи проблему, підтримуючи один одного під час їхніх питань - це знову ж таки співпраця.

Отже, я можу сказати, припиніть звинувачувати гру, звинувачувати ігри - це характеристика співпраці ще раз.

Коли всі починають мислити спільно в одному напрямку, одне і те ж мислення і працювати над одними і тими ж аспектами і практиками, це знову є співпрацею, як завжди, коли розробляється якась нова функція, кожен думає про те, як це перевірити, як розгорнути це, як відстежувати це, це співпраця.

Отже, спільне мислення всередині команди ще раз є характеристикою співпраці.

Давайте зробимо перерву зараз і зрозуміємо трохи більше про співпрацю в нашому наступному відео.

НАЗАД Підручник | НАСТУПНИЙ підручник

Рекомендована література

^