Представим, что вы работаете в небольшой компании, занимающейся, например, ритейлом. Вы – руководитель IT-отдела. Компания у вас небольшая, человек, скажем 30, IT-персонала: десяток разработчиков, архитектор, парочка DevOps-специалистов, QA-инженеров, менеджеры, аналитики, специалисты поддержки.
У вас все идет хорошо – бизнес растет, задачи закрываются, багов немного, но и те, что есть – некритичные и не приводят к простою и потере денег и клиентов. Точнее, шло хорошо, потому что в определенный момент вы стали замечать, как время time-to-market стало увеличиваться, релизы растягиваться, количество багов тоже расти. Последней каплей было, когда однажды, в летнюю ночь с субботы на воскресенье, вас разбудило не пение птиц, а звонок дежурного разработчика с теми самыми словами, которые не хочет слышать никто и никогда – база лежит, рабочих бэкапов за последний месяц нет.
Понимая, что утро сегодня начинается не с кофе, вы, вскакивая с постели, даете инструкции разработчику, где взять бэкапы и что делать с отсутствующими данными, а в голове все крутится мысль – “Я же говорил! Говорил, что нужно тестировать бэкапы”. Но как тестировать бэкап, когда его размер уже перевалил за 4 терабайта? Бухгалтерия ни за что не одобрит расширение в 2 (а, может быть, и в 3) раза затрат на инфраструктуру. Возможно, получится пробить увеличение бюджета теперь, когда есть козырь в рукаве. Не стоит экономить на том, что спасет бизнес.
“Пу-пу-пу-пу” – вырвалось у вас на автомате. “Мяяяяяу” – вырвалось у кота. Ведь если двуногий встал с кровати, это означает одно – пришло время есть. Накормив кота, починив сервер вместе с ведущим разработчиком на пару, оценив потери от простоя длинною в 6 часов, и, наконец-то, сварив себе кофе, вы решили: “Пора что-то менять”. Эти выходные вы проведете в тяжких думах о судьбе IT-инфраструктуры и процессов в вашей компании.