Девопсятина: почему у ФБК всё так плохо с айти
Слышали про такую штуку, как иммунологическая сенсибилизация? Которая представляет собой чрезмерный и увеличивающийся ответ организма на раздражитель? Недавно у меня произошла третья итерация этого занимательного процесса.
Если интересуетесь теми немногочисленными ошмётками, которые представляет собой сейчас политика в России, то наверняка слышали про бурления вокруг "Умного голосования" ФБК в преддверии следующих выборов. А именно - про слитую базу подписчиков и последовавшие события.
Вкратце - у достаточно давно уволенного и, по всей видимости, переметнувшегося на тёмную сторону бывшего сотрудника сохранились действующие реквизиты доступа к админке компании, рассылающей от лица ФБК письма. Это довольно серьёзный косяк ИБ, но мой кредит доверия к организациям Навального столь высок, что даже утёкшая почта всех единомышленников не вызвала сильного негодования. Бывает.
Далее, в середине лета, один энтузиаст с Хабра опубликовал небольшую статью, в которой рассказал про то, как нашёл (без особого труда) открытую всем ветрам вебморду управления Kubernetes-кластером, где можно было увидеть все потроха в виде списка контейнеров, логов сервисов и даже реквизитов для подключения к базам и облакам. Консолидировав всю свою веру в ФБК, я сумел подавить вопль ярости и состряпал внутри головы довольно жалкое оправдание вида "ну, может у них админ уволился, а на его место пришёл девопс?". Было грустно, но не так, чтобы совсем.
Спустя два месяца, в конце августа, был опубликован ещё один материал той же направленности - в этот раз оказалось, что у API на сайте "Умного голосования" не выключен дебаг-режим, поэтому снова видны все потроха и версии ПО, достаточно старые для того, чтобы нашлась действующая критическая уязвимость, через которую можно пролезть в базу, внутрь контейнера и далее по списку... Последняя соломинка сломала-таки спину верблюда - и у меня не по-детски припекло.
Конечно же, можно вспомнить, что ФБК - не какой-то там IT-гигант, у которого все процессы вылизаны до блеска. Понятно, что в условиях постоянного прессинга от государственных силовых структур не до того, чтобы придирчиво сравнивать между собой кандидатов на собеседованиях, выбирая более лучшего. С другой стороны - колоссальная ответственность за доверившихся ФБК людей, данные которых, попав в костлявые лапы, могут привести к вполне осязаемым проблемам в виде увольнений с работы (уже) и, потенциально, уголовным делам (слава богу, пока ещё нет).
Мне одному очевидно, что, противостоя полицейскому государству в XXI веке, нужно максимально обезопасить себя по всем фронтам?
Специфика IT в том, что для наведения лютой секьюрности не требуется, в отличие от других аспектов жизни, существенных усилий и больших денег - не требуется круглосуточная охрана, надёжные сейфы и дорогущие системы датчиков проникновений. Достаточно нормального квалифицированного сисадмина.
Можно долго пенять господину Волкову за его дурацкий стиль общения в соцсетях и странные управленческие решения - но ради подобной частности я не стал бы расчехлять перо и тратить время читателей.
Потому что озвученная проблема не единична и имеет, на мой взгляд, системный характер.
Как и интернет в целом, IT-индустрия в последние десятилетия страдает от последствий собственного успеха и повсеместного распространения. В IT теперь крутятся столь огромные деньги, что привлекают разного рода "специалистов", размывающих стройные доселе концепции, выстраданные красноглазыми инженерами в свитерах.
Первым звоночком стал термин "гибкая разработка". Осознав, что традиционная методология, известная как "водопад", обладает некоторыми принципиальными недостатками, люди начали думать, что с этим можно поделать. И придумали процесс, при котором задача разбивается на небольшие части, добавляемые к продукту постепенно, в ходе коротких циклов - "спринтов". Звучит отлично, но на практике внедрение столкнулось с традиционными для нас, неидеальных созданий, перекосами - как в собственно разработке, так и в (и особенно в) управлении. На эту тему написаны сотни прекрасных ироничных текстов, демонстрируя масштаб проблемы, не поленитесь загуглить.
Затем пришёл черёд "микросервисной архитектуры", отлично дополняющий (особенно в теории) предыдущего участника. В самом деле - зачем разрабатывать огромное приложение, в котором сосредоточена ВСЯ функциональность, если можно вместо этого сделать несколько небольших сервисов, каждый из которых занимается чем-то своим? Легче вносить изменения, легче тестировать и локализовывать баги. На практике же десятки общающихся между собой по какому-нибудь HTTP сервисов часто страдали от несогласованности данных, нетривиальности обслуживания и других проблем, присущих сложным распределённым системам.
Далее сумрачный гений пришедших в IT маркетологов исторг из себя "вычислительные облака" - последователей виртуализации, более гибких, с гораздо более богатыми возможностями, а главное - гораздо более дорогих, поскольку в облаке, располагающимся на мощностях какого-нибудь Амазона, Гугла или Майкрософта вы платите АБСОЛЮТНО ЗА ВСЁ - за такты процессора, мегабайты памяти, гигабайты диска, октеты переданных по сети пакетов, за IP-адреса, правила маршрутизации и DNS-запросы. Предполагается, что подобная гибкость и плата "ровно за то, что используешь" существенно превосходит капитальные затраты на покупку или аренду железа. Так действитальное бывает, но в каждом отдельном случае нужно тщательно и пристрастно считать.
Гибкая методология разработки, при которой изменения в код микросервисов вносятся ежедневно, и при каждом таком случае нужно запускать CI-пайплайны, отлично просочеталась с облаками. Всё это многообразие новых процессов породило другое многообразие - инструментов управления. Как грибы после дождя, начали появляться системы контейнеризации, системы управления контейнерами, системы оркестрирования, масштабирования, мигрирования, бэкапирования...
Старый-добрый бородатый сисадмин с цисками и башем наперевес почувствовал себя слегка на обочине истории.
Гром грянул, когда уже упомянутые мною "специалисты" пришли к менеджерам с красивыми графиками в презентациях и спросили - "знаете ли вы, что 68% рабочего времени админы кукуют, плюя в потолок?". Менеджмент, понятное дело, в большинстве случаев вошёл в агро-режим. "Специалисты" же, ловко эксплуатируя полученную эмоцию, встали в третью позицию и заявили, что существует простое и эффективное решение проблемы. Нужно было просто найти, чем занять админов.
Предыдущий параграф представляет собой чистой воды вымысел, но совершенно не исключено, что дело было именно так...
...послужив моментом рождения "великого и ужасного" DevOps`а.
Пасьянс сложился идеально - частые релизы, необходимость в постоянном запуске трудоёмких и зачастую довольно запутанных процессов CI, микросервисы внутри контейнеров, облачные вычисления, масса разнообразных сервисов управления, работающих "из коробки". А рядышком - "недозагруженный" админ в качестве идеального кандидата для взваливания всего этого богатства на плечи.
В результате мы имеем следующее положение дел в индустрии - никому не нужен "просто админ", теперь всем подавай девопсов. Работодатели разделились на две неравные части. Первая, относительно небольшая - отправила своих админов повышать квалификацию, овладевая новыми инструментами и повысила им зарплату кратно увеличению зоны ответственности. Вторая - сделала то же самое добровольно-принудительно и без улучшения материального обеспечения, чем вызвала отток сисадминов и постепенную замену их на "молодых, энергичных девопсов".
Хоть и имея более чем десятилетний стаж работы в IT, я вряд ли могу назвать себя каким-то там труъ-олдскул-админом. Оценивая по возможности беспристрастно и добавив немного синдрома самозванца, я прихожу к выводу, что я скорее крепкий боровичок чуть выше среднего. Однако тот факт, что начало моего айтишного пути пришлось на время, когда интернет всё-таки ещё не был тем проходным двором, что сейчас, сформировал некоторый техническо-мировоззренческий фундамент, коим я пользуюсь до сих пор и который доселе ни разу меня не подводил. Можно назвать это количеством опыта, наконец-то перешедшим в качество, высокоуровневым пониманием, интуицией или ещё как-то.
Сначала купи картину, а затем рамку (с) Козьма Прутков
Многочисленные экспресс-курсы, обещающие сделать из вас девопса за пару недель, заполонили профильные интернет-ресурсы. И количество выпускников оных, судя по всему, достигло некоторой критической отметки, повлияв на глубинные IT-процессы компаний. Оставив качество такого образования за скобками, хочу сказать только, что принцип "овладей используемым инструментом во всех нюансах", видимо, был послан далеко и надолго.
Конечно же, людей очаровывает простота, с которой теперь, воспользовавшись одним из многочисленных наборов "для кубернетиса", можно буквально за десятки минут развернуть полноценную инфраструктуру. Кажется, что прогресс унёсся куда-то за горизонт от неуклюжих и медленных тыканий и линуксовую консоль. Всё в облака! Всё в браузерные панели управления! Всё работает из коробки!
Что же я вижу, протерев очки от розового маркетингового мармелада?
Я вижу кучу людей с сертификатами приснопамятных курсов девопсов, жаждущих "ворваться в айти", но не имеющих, по факту, особо никаких фундаментальных знаний, да и модные технологии освоивших лишь поверхностно и клочковато. С помощью Stack Overflow и такой-то гугломатери они, несомненно, способны относительно успешно развернуть какую-то инфраструктуру, нагромоздив одно "изкоробочное" решение на другое.
Будет ли такое поделие производительно? Будет ли оно финансово-эффективно? И, что самое главное, возвращаясь к началу разговора - будет ли оно безопасно?
Над ответом оставляю вас подумать самостоятельно.
P.S. У кого-то после прочтения текста может сложиться впечатление, что ваш покорный слуга - какой-то луддит от сисадминства, окопавшийся среди знакомых бирюлек и брызгающий слюной на всё новое. Это правда, но лишь отчасти - я действительно осторожно, хоть и с оптимизмом смотрю на технологии, возлежащие на волне хайпа. Другое дело, что никакая технология по определению не является серебряной пулей и спектр ситуаций, в котором оправдано её применение - ограничен. Что лучше подойдёт для конкретного случая - задача для тщательного продумывания системным архитектором. А никак не менеджментом, насмотревшимся красивых презентаций.