3 причини, чому розробникам потрібно інтегрувати інструменти Agile та ITSM

Ці методи допомагають трансформувати дві основні ІТ-функції організації з розробки: розробку (створення нових додатків і часте підвищення якості) та операції (забезпечення надійності та продуктивності бізнес-систем, баз даних і додатків).

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

Які бізнес задачі може закрити система управління задачами – CRM

Гнучкість і інтеграція інструментів ITSM

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

Для багатьох компаній ці робочі процеси поєднують в собі гнучкі методи, які використовуються командами розробників, включаючи Scrum і Kanban, з методами управління ІТ-послугами (ITSM), включаючи:

• управління вимогами
• управління інцидентами
• управління проблемами
• управління змінами та підтримку бази даних керування конфігурацією (CMDB)

Однак багатьом ІТ-організаціям не вдається інтегрувати свої інструменти Agile та ITSM.

Групи розробників можуть використовувати Azure DevOps, Digital.ai, Jira Software або інший гнучкий інструмент для керування відставаннями користувацьких історій, спринтів і випусків у процесі розробки. Незважаючи на це, можна використовувати BMC, Cherwell, Ivanti, Jira Service Management, Micro Focus, ServiceNow або будь-який інший інструмент ITSM для керування квитками, відстеження систем та контролю за керуванням змінами.

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

Якщо вам цікаво, чому важливо під’єднати ці інструменти та робочі процеси, зверніть увагу на три загальні точки інтеграції, які потрібні Devsecops для підтримки швидкого розгортання, безпеки та стабільної роботи:

Прискорити впровадження змін з низьким ризиком

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

Цей підхід може знадобитися для організації найскладніших розгортань, які включають багато команд, системні залежності або операційні ризики. Багато практик devops вже спрямовані на мінімізацію цих проблем. Мікросервіси, оснащені надійним безперервним тестуванням і CI/CD, дозволяють командам розробників, наприклад, вносити невеликі зміни з меншим ризиком. Іншими змінами з меншим ризиком можуть бути компоненти UX, розгорнуті в безсерверних архітектурах, зміни до вбудованих інформаційних панелей аналітики, покращення програм з низьким кодом або невеликі зміни в конфігурації Dataops.

Якщо зміни справді невеликі, з низьким рівнем ризику, чи можуть ІТ-спеціалісти автоматизувати схвалення змін, поєднуючи CI/CD, ініційовані гнучкими інструментами, з робочими процесами керування змінами, керованими за допомогою інструментів ITSM?

Звичайно, компанії, розробка, безпека та операції повинні домовитися про те, що означають «низький ризик» і «невеликий». Крім того, конвеєри CI/CD повинні підтримувати відкат, і, в ідеалі, менеджери інцидентів повинні мати можливість ініціювати їх, коли зміни призводять до непередбачених проблем.

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

Розставити пріоритети та виправити виробничі помилки

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

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

Призначення не є тривіальним у виконанні, оскільки команди повинні відображати статус робочого процесу між помилками в інструментах Agile і квитками в ITSM. Крім того, деякі квитки можуть призвести до кількох дефектів або кілька квитків можуть бути пов’язані з одним дефектом. Імовірно, у цих робочих процесах також будуть інші винятки, наприклад, коли служба обслуговування пов’язує запит запиту з дефектом, але команда розробників каже, що користувач насправді запитує нову роль.

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

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

Поєднати розгортання з платформами моніторингу

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

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

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

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

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

• Гнучка розробка, контроль версій, позначення функцій, автоматизація тестування та інструменти CI/CD, які використовуються командами розробників
• Інструменти ITSM для запису інцидентів, запитів і змін, якими керує служба обслуговування
• CMDB і інструменти відображення залежностей і виявлення, які фіксують точні стани інфраструктури
• Інструменти моніторингу та AIOps, які використовуються центрами мережевих операцій та операційними центрами безпеки
• Картографування потоків створення цінностей та інші інструменти управління продуктом для забезпечення видимості та контролю для керівників

Інструменти керування для цілей AIops, спостережливості та рівня обслуговування включають BigPanda, Broadcom, DataDog, Devo, Digitate, Dynatrace, Elastic, Micro Focus, Moogsoft, New Relic, Nobl9, OpsRamp, Resolve, ScienceLogic, Splunk та інші. Вони змагаються за інтеграцію, аналітику, робочі процеси, автоматизацію та інші функції, які допомагають відстежувати та виправляти експлуатаційні проблеми.

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

Agile та DevOps для проектних менеджерів

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

Як покращити управління проектами вашої компанії