Техпідтримка в епоху DevOps




DevOps йде у великі ІТ-компанії незалежно від того, готові вони до цього чи ні. Тут може зустрітися багато проблем, і я хотів би поговорити про одну з них. Можливо, це занадто смілива заява, але я вважаю, що поточна організаційна структура більшості служб ІТ-підтримки в корені хибна.
У такій ситуації успішне впровадження DevOps-практик може виявитися практично неможливим.
В якості альтернативи я хотів би запропонувати нову методологію під назвою Swarming, яка вже готова до впровадження у великому бізнесі і ідеально підходить для виконання завдань технічної підтримки в еру DevOps.
Поточна ситуація: консерватизм трирівневої системи техпідтримки
Нам слід почати з невеликого огляду сформованих керуючих структур, які лежать в основі переважної більшості служб техпідтримки в організаціях, що належать до середнього і великого бізнесу.
Класична техпідтримка, побудована згідно з принципами управління ІТ-сервісами (IT Service Management), має трирівневу ієрархію.
  • Рівень 1. Це знаходиться в безпосередньому контакті з користувачами — зазвичай по телефону — служба технічної підтримки (Service Desk). Націлена на надання техпідтримки середнього рівня по неспеціалізованим питань. Основне завдання — підтримка стабільного якості послуг за умови вирішення більшості вступників запитів тут же, на першому рівні.
  • Рівень 2. Зазвичай тісно пов'язаний з першим, але має на увазі більш глибокі загальні чи спеціальні знання та навички співробітників. Фахівці другого рівня, наприклад, можуть проходити додаткове навчання щодо підтримки поширених операційних систем (таких як Microsoft Windows) або апаратного забезпечення, отримуючи необхідні навички для вирішення більш складних проблем.
  • Рівень 3. Тут знаходяться команди, що спеціалізуються на конкретних технологіях або додатках. Компанії, які самостійно розробляють програмне забезпечення, часто організовують окремі команди підтримки для певних додатків і сервісів.
Для кращого розуміння трирівневої структури потрібно провести аналіз породили і підтримують її бізнес-причин. Розглянута методологія застосовується практично повсюдно. Існує кілька переваг, які стимулюють її використання.
  • Клієнтам надано єдиний канал спілкування з техпідтримкою незалежно від природи проблеми.
  • На ринку праці легко знайти фахівців з технічними навичками, необхідними для роботи на перших двох рівнях підтримки. Це також полегшує передачу завдання на аутсорс, що робиться досить часто.
  • Фахівці з конкретних питань і областях ізолюються від спілкування з клієнтами і отримують на виконання завдання, що відносяться тільки до сфер їх компетенції.
Подорож клієнтського звернення в службу підтримки може закінчитися вже на першому рівні, практично не розпочавшись. Фактично у багатьох організаціях частина звернень обробляється з допомогою повністю автоматизованих сервісів, які часто називаються «нульовим рівнем» (Level zero).
Проте є багато проблем, які не вдається вирішити на першому рівні. Процес їх передачі на рівні 2 і 3 називається ескалацією:


Фахівці другого рівня зазвичай обробляють менше заявок, ніж їх колеги з першого, але це більш складні завдання, в середньому вимагають більше часу на рішення.
Тікети, добралися до третього рівня (эскалированные з другого або надіслані прямо з першого), зазвичай становлять невелику частину всіх звернень, що надійшли. Але це найскладніші завдання, вирішення яких вимагає високої майстерності фахівців і значних тимчасових витрат.
Було зроблено чимало спроб розрахувати порівняльну вартість рішення проблеми на кожному з рівнів підтримки. У цій роботі 2014 року, наприклад, середня вартість закриття тікета на першому рівні оцінюється в 22 $, на другому — в 62 $, а на третьому — 85 $ (згідно з іншими дослідженнями остання цифра більше в кілька разів).
Проблеми трирівневої моделі
Критикувати таку загальноприйняту структуру зовсім непросто. Однак Swarming-рух розраховує саме на це, взявши за основу суттєві, але виправні недоліки багаторівневої моделі. Давайте розглянемо деякі проблеми, що зачіпають DevOps.
  • Багаторівнева підтримка передбачає кілька черг. Оскільки перший рівень прагне вирішувати проблеми максимально швидко, все, що не вдалося виправити відразу, ставиться в чергу. Фактичний статус проблеми міняється, і вона переходить з розряду поточних відстрочені. По суті рівні 2 і 3 є складами завдань, що знаходяться в процесі виконання (Work in Progress), що є проблемою в рамках Lean-філософії, яка лежить в основі DevOps. Успішне впровадження DevOps як частини Lean вимагає рішучих кроків по скороченню незавершеного будівництва (Work in Progress). Вже тільки ця проблема є суттєвим стримуючим фактором приходу DevOps в технічну підтримку.
  • Багаторівнева підтримка може заблокувати шлях до потрібного фахівця. DevOps ратує за збільшення самостійності і залученості співробітників. Заохочується підтримка коду самими розробниками. Компаніям, практикуючим DevOps, вдається досягти більш високих швидкостей обробки звернень користувачів (згідно звіту «Стан DevOps» (State of DevOps) за 2016 рік в 24 рази швидше). Але від цього немає ніякої користі, якщо тікет повинен прорватися через кілька черг, перш ніж потрапити до потрібного фахівця. Одного разу під час обговорення впровадження Swarming в службі підтримки користувачів один з менеджерів підтримки BMC (Бі-ем-Сі) поставив слушне запитання: «Чому ми поміщаємо наших кращих людей в кінці ланцюжка?»


  • Багаторівнева підтримка призводить до «отфутболиванию» звернень. В багаторівневій техпідтримці завдання в односторонньому порядку призначається виконавцю. Це може бути зроблено на попередньому рівні або в іншій команді фахівців. Виконавець вперше бачить заявку в той момент, коли вона з'являється в його черги завдань. На жаль, тікет часто відправляється назад, оскільки або фахівцям потрібна додаткова інформація або призначення виявилося помилковим. DevOps заснований на співробітництві між професіоналами: розробниками, тестерами, фахівцями служб експлуатації і т. д. Вертикальні і горизонтальні бар'єри між підрозділами, властиві багаторівневої підтримки, а також пасивна (без участі приймаючої сторони) передача завдань абсолютно не відповідають духу міждисциплінарної взаємодії і співпраці.


  • Багаторівнева підтримка не вирішує проблему перевантаженості фахівців-експертів (Subject Matter Experts). Хоча багаторівнева підтримка і вирішує проблему передачі експертам занадто легкі для них питань, вона не захищає їх від завалювання складними завданнями. «Герої» — справжній бич Управління ІТ-сервісами (ITSM). Це розумні люди, які, як здається на перший погляд, приносять відчутну користь організації і регулярно творять чудеса, вирішуючи складні проблеми. Насправді такі герої — перевантажена роботою єдиної точки відмови. Вони вільно чи мимоволі є хранителями життєво важливих для організації знань і схильні до вигорання. Багаторівнева підтримка, будучи лінійної та ізолюючої структурою, не робить нічого, щоб запобігти культ Героя, і, мабуть, навіть підтримує його. В процесі зміщення традиційного бізнесу у бік DevOps ми бачимо збереження такої схеми роботи, коли ключові члени команди DevOps поміщаються в кінці ланцюжка ескалації. Збиток у DevOps-сценарії, можливо, ще більший: ключові розробники відсторонюються від новаторства і змушені займатися вирішенням эскалированных і вже втратили час звернень користувачів.


Swarming в якості альтернативи
«Засновані на співпраці співтовариства можуть долати професійні та організаційні бар'єри, стимулюючи кооперацію, навчання і прогрес».
(Don Tapscott і Anthony D. Williams, Wikinomics
Концепція Swarming була запропонована наприкінці минулого десятиліття в якості нової платформи для організації технічної підтримки. Вона в явному вигляді відкидає консервативну багаторівневу структуру на користь моделі мережевої взаємодії:

Джерело: Consortium for Service Innovation


Ключовою компанією, яка першою почала впроваджувати цю систему, була Cisco. У 2008 році у документі під назвою Digital Swarming вона представила «Модель розподіленого співробітництва та прийняття рішень». Концепція була прийнята організацією Consortium for Service Innovation, трансформувавшись Intelligent Swarming. Деякі з її принципів свідчать:
  • Не повинно бути розділених на рівні груп підтримки.
  • Не повинно бути ескалації від однієї групи до іншої.
  • Завдання повинна передаватися безпосередньо того співробітника, який напевно зможе її вирішити.
  • Людина, що прийняла звернення, відповідає за нього до кінця.
Swarming на практиці: приклад структури для DevOps
У Swarming немає єдиної чітко визначеної структури. Почасти це пояснюється новизною і, відповідно, малої поширеності. Однак показаний нижче приклад (заснований на swarming-методи підтримки користувачів, які застосовуються в BMC) є типовим. Він істотно поліпшив роботу служби підтримки (про що було розказано на UK's Servicedesk and IT Support Show в 2015).
Swarming починається при появі проблеми, яку неможливо вирішити відразу в момент отримання звернення від користувача. Швидка первинне сортування завдання закінчується її відправкою в одну з двох груп (Swarms):

Первинне сортування в структурі Swarm


Кожна група (Swarm) — це невелика команда, яка обробляє надходять заявки в режимі, близькому до реального часу:
«Severity 1» Swarm (Група по роботі з інцидентами першого ступеня тяжкості)


  • Три співробітника, що працюють в умовах запланованої щотижневої ротації.
  • Основна увага: надати негайну відповідь, вирішити завдання як можна швидше.
Ця група націлена на вирішення серйозних проблем. Її учасники координують реакцію на складні ситуації, підключають потрібних людей, намагаються організувати максимально швидке вирішення критичних проблем. Цей процес не сильно відрізняється від процедури реакції на серйозні події (Major Incident), яка застосовується в традиційній багаторівневої моделі. Однак паралельно розгорнута і інша група, обробна набагато більшу кількість звернень:
Dispatch Swarm (Група диспетчеризації)


  • Проводить зустрічі кожні 60-90 хвилин.
  • Сфокусована на регіонах і продуктових лінійках.
  • Основна увага: «схопити вишеньку» (в першу чергу братися за те, що можна виправити дуже швидко).
  • Вторинна завдання: перевірка звернень перед їх відправкою командам підтримки продуктових лінійок.
Цей тип груп з'явився в якості відповіді на основну проблему багаторівневої підтримки: безліч звернень, які могли бути вирішені дуже швидко при попаданні до правильного фахівця, губляться в списках незавершених завдань. Таким чином, рішення п'ятихвилинного питання може розтягуватися на дні.
Учасників цієї групи буквально підштовхують до того, щоб «хапати вишеньки», не звертаючи уваги на проблеми, які не можна виправити миттєво. Таким чином, час, що витрачається на вирішення значної кількості типів завдань, може бути сильно скорочено.
Є і додаткова вигода. Включення до складу недосвідчених співробітників призводить до того, що вони отримують знання, доступ до яких в багаторівневій моделі з'явився б тільки при перекладі в вузькоспеціалізовану команду. У той же час висококваліфіковані фахівці третього рівня підтримки виявляються ближче до клієнта.
Використання Dispatch Swarming призводить до швидкого розв'язання значної кількості завдань (BMC їх кількість становить приблизно 30%), а решту звернення потрапляють в черзі більш звичних команд підтримки, які займаються окремими лінійки продуктів. Тут багато завдання будуть знайомі і зрозумілі пересічним членам команди, тому їх рішення не повинно викликати труднощів. При цьому ще одна частина звернень (можливо, близько 30%) можуть виявитися варті уваги кращих фахівців служби підтримки незалежно від їх структурної належності.
Тут використовується група третього типу: Backlog Swarm.


Backlog Swarm (Група роботи з усіма завданнями)


  • Проводить зустрічі регулярно, зазвичай щодня.
  • Основна увага: рішення складних завдань, отриманих від команд підтримки продуктових лінійок.
  • Вторинна завдання: заміна одиночних експертів.
Для вирішення найбільш складних проблем Backlog Swarm об'єднує групи досвідчених і кваліфікованих інженерів, незважаючи на географічні і структурні кордону. Вони отримують завдання від фахівців на місцях, яким тепер заборонено безпосередньо звертатися до експертів індивідуально. Замість цього вони повинні передавати завдання у відповідний Backlog Swarm.
Приклад використання Swarming
При роботі класичної техпідтримки в зв'язці з DevOps проблеми багаторівневої моделі тільки посилюються. В цьому випадку активно накопичуються невирішені завдання (Work in Progress backlogs), що, в свою чергу, обмежує самостійність і гнучкість. Така система за своєю суттю є ізолюючої. Перераховані проблеми суперечать філософії DevOps і є головним викликом на шляху впровадження DevOps-практик в організаціях з традиційною моделлю ведення бізнесу.
Вже зараз можна виділити наступні негативні моменти.
  • DevOps заохочує розробників програмного забезпечення брати на себе його підтримку (що в народі називається «сам написав — сам і розбирайся»). Однак у розвинених службах підтримки, характерних для великих організацій, багаторівнева структура є основним каналом, за яким проблеми користувачів добираються до інженерів. Як ми вже знаємо, бар'єри між першим рівнем підтримки та командної DevOps можуть призвести до затримки в вирішенні проблем, а також до неякісної первинної обробки звернень.
  • Модель інтеграції типу «викинь це за паркан», застосовувана між ITSM-системами прийому заявок та інструментами забезпечення життєвого циклу програмного забезпечення DevOps-команд, що призводить до нестачі ситуаційної обізнаності співробітників.
  • Спроби насильно впровадити вертикальні і горизонтальні бар'єри створюють перешкоди при взаємодії фахівців різних підрозділів — ключовому елементі успішного застосування DevOps.
Навпаки, концепція Swarming побудована в чому на тих же принципах, які знаходяться в основі успіху DevOps.
  • Динамічний крос-функціональне співробітництво, що дозволяє зібрати в одну команду фахівців, які володіють різними навичками і сферами компетенції.
  • Гнучкі команди на противагу косным ієрархічним структурам.
  • Самостійність у противагу догматичним процесів (ключовим прикладом тут є можливість «хапати вишеньки», працюючи в складі Dispatch Swarm).
  • Зменшення кількості очікують вирішення завдань.
  • Обмін навичками та досвідом між фахівцями різного профілю.
Висновок
«Великий бізнес не тому змінюється повільно, що там працюють дурні або ненавидять технології люди. Просто у них є користувачі».
(Luke Kaines, засновник і генеральний директор, Puppet Labs. Configuration Management Camp, Бельгія, 2015)
DevOps ставить під сумнів саму суть сталих консервативних методів роботи, об'єднуючи раніше ізольовані ролі розробників і фахівців служб експлуатації, а також намагаючись позбутися вкорінених неефективних практик. Ця філософія здебільшого (якщо не повністю) сформувалася в організаціях нового покоління, часто не мали необхідності підтримувати застарілі, але працюючі системи та їх користувачів.
Важливо відзначити, що це було зроблено досить успішно:

Джерело: Звіт про стан Devops за 2016 рік
Тепер DevOps дістався до традиційних організацій, де в процесі впровадження (часто дуже болючого) йому належить зіткнутися з новими викликами. Але для таких компаній це вже не питання поліпшення, а необхідний крок у боротьбі за виживання. Зміни у формі «творчого руйнування» є постійною і реальною загрозою існуванню великих компаній. Тільки 12% списку Fortune 500 від 1955 року залишалися в ньому і в 2014.
ІТ-компанії повинні намагатися скрізь, де тільки можливо, використовувати свіжі ідеї і постійно ставити під сумнів консервативні практики.
Swarming-рух почав атаку на модель багаторівневої підтримки, але прогрес в управлінні ІТ-сервісами традиційних компаній йде повільно, оскільки він обмежений рамками використання лише в декількох далекоглядних організаціях. Однак близькість основних елементів Swarming і DevOps складно заперечувати, і тому вони мають схожі проблеми впровадження, рішення яких робить простіше використання обох систем.
Таким чином, існує необхідність переосмислення моделі багаторівневої підтримки. Нова методологія повинна використовувати переваги DevOps, зберігаючи працездатність і ефективність у масштабах великих компаній. Думаю, що Swarming цілком може підійти на цю роль.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.