Найважливіші уроки про автоматизацію я отримав не в IT.

Кожна автоматизація починається не з правильного питання

Коли я бачу чергове монотонне ручне завдання, більшість людей одразу запитує: «Як це автоматизувати?»

Моє перше питання майже завжди інше: «Чому цей процес взагалі працює саме так?»

З роками я зрозумів, що саме це питання найчастіше приводить до правильного рішення. Ця звичка з'явилася в мене задовго до роботи з Linux, Docker чи DevOps. Вона прийшла з реального виробництва.

Конвеєр, який сам себе дряпав

До переходу в IT я багато років працював в управлінні виробництвом на великому заводі побутової техніки. Ми не займалися звичайним складанням готових машинокомплектів — це був повний цикл виробництва, від рулону металу до готового упакованого виробу.

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

Для більшості працівників це вже стало нормою:

  • — «Так буває.»
  • — «Конвеєр працює швидко, без цього ніяк.»

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

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

На одному з проміжних етапів оператор свердлив отвори в корпусі для кріплення плати. Дрібна металева стружка падала прямо на конвеєрну стрічку. Сама стрічка була покрита м'якою гумою саме для того, щоб захищати пофарбовані поверхні деталей. І саме це стало проблемою.

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

Ми просто змінили порядок операцій та додали видалення стружки пилососом безпосередньо в момент свердління. Кількість пошкоджених виробів моментально зменшилася з 16.7% до 1.3%. Без купування нового обладнання, без дорогих інвестицій та без жодної автоматизації. Ми просто усунули причину.

Через роки я побачив ту саму проблему в IT

Минуло багато років. Я працював уже з інфраструктурою, автоматизацією та DevOps. І одного дня зрозумів, що досі вирішую завдання абсолютно так само.

Один із нещодавніх проєктів був пов'язаний з автоматичним плануванням оптимальних маршрутів для сервісних інженерів. На перший погляд, це виглядало як класична задача маршрутизації (VRP). Здавалося, що головне — правильно налаштувати та запустити Google OR-Tools.

Але дуже швидко стало зрозуміло, що алгоритм взагалі не є головною проблемою. Справжні труднощі були зовсім в іншому:

  • — адреси вводилися користувачами в десятках різних форматів;
  • — багато заявок взагалі не містили координат;
  • — бізнес-правила накопичувалися роками й містили купу взаємовиключних винятків;
  • — частина даних була просто неконсистентною.

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

Автоматизація — не завжди покращення

Іноді я уявляю, як ми могли б вирішити проблему на заводі по-іншому. Наприклад, встановити наприкінці конвеєра дорогого промислового робота, який би автоматично перефарбовував усі подряпані вироби. Звучить абсурдно, чи не так?

Але в IT ми робимо подібне набагато частіше, ніж здається. Замість того щоб розібратися, чому процес працює неправильно, ми пишемо ще один скрипт. Потім ще один cron. Потім запускаємо ще один контейнер, потім — ще одну систему моніторингу. У результаті ми автоматизуємо не процес. Ми автоматизуємо його недоліки. І чим якісніше працює така автоматизація, тим швидше ці недоліки накопичуються та множаться.

Здоровий глузд, описаний у методологіях

Багато речей, які здаються просто здоровим глуздом, давно описані та стандартизовані в класичних методологіях:

  • — PDCA (Plan-Do-Check-Act) навчила мене, що будь-яке системне покращення починається не з впровадження інструментів, а зі спостереження та точного вимірювання.
  • — Lean (Ощадливе виробництво) змусив шукати не нові технології, а зайву роботу та кроки, які можна взагалі прибрати (Muda).
  • — Теорія обмежень (Theory of Constraints) чітко показала, що майже кожна система має лише одне справжнє вузьке місце, і оптимізація всього іншого не приносить відчутного результату.

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

Технології змінюються. Спосіб мислення — ні.

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

«Яку проблему цей процес насправді намагається вирішити?»

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