ДевОпс с InfoScale

Джун VS Сеньор: противостояние века или как? Джун в production - это страшный сон любого сеньора. Вообще, между нами говоря, джуны в продакшн попадать и не должны, но далеко не все проекты предусматривают наличие таких роскошных условий и ресурсов, чтобы нет-нет, да и не понадобилось бы джуна припахать к финальной доработке. И вот тут уже появляются мифы, легенды и, конечно же, многочисленные мемы. Но, как делится с нами наш тим-лид Илья, лично на его практике ему еще не попадался ни один сеньор, который бы не сломал, лего и играючись, весь production словно карточный домик. Угадайте, сколько раз прилетало бедным джунам? Статистика хоть и не 100%, но достаточно удручающая. То есть, в принципе, нельзя отрицать вероятности такого события, что на самом деле это сеньор плохо “докрутил какой-то винтик” в продакшене, а многострадального джуна отправил туда просто для того, чтобы рухнуло все именно в его руках. Но, как говорится, мем смешной, а ситуация - страшная. А еще больше мемов, а заодно и их задушевные разборы и обсуждения, вы можете найти здесь - httpswww.youtube.com/...21s

Как DevOps-инженеру не стать “примером как не надо” Сегодня наш топовый тимлид любезно согласился поделиться с нами своим мнением на тему того, кто, в его понимании, специалисты высокого класса. Понятное дело, что такое звание абы кому не дадут. И невозможно стать DevOps, просто посмотрев ролик на YouTube; научившись запускать хром в докере на компьютере или ноуте; отправив в гит свою “домашнюю” папку с мемами с котятами. Как же тогда понять, что ты уже выше простых смертных-админов и паришь в DevOps-небесах? Квалификация именно опытного инженера - это многолетний опыт. В частности, выстроенный, в буквальном смысле, потом и кровью. Так, в нашей DevOps-команде, состоят только те инженеры, в которых мы уверены на все 200% процентов. И для того, чтобы принять их под крылом InfoScale потребовалось не раз проверить их способности мыслить и выстраивать логические цепочки, наличие технического кругозора и реального опыта.

Рассказываем о том, почему микросервисы - не панацея Как то раз нам попался довольно интересный кейс. В чем был основной интерес: он достался нам не просто с 0, а после работы над ним другого DevOps. Мы не будем пускаться в долгую критику коллеги, но просто скажем, что…там было все достаточно интересно. Микросервисы - это прекрасно, чудесно и удобно. Еще бы: разбиваешь все на запчасти и засовываешь в контейнеры. Особенно классно, когда одну здоровенную программу получается разложить на множество отдельных небольших компонентов, каждый из которых можно рассматривать и развивать по отдельности. И это классно! Но во всем надо знать меру, в конце концов! Вот тот самый DevOps ее явно не знал. И программа в итоге напоминала лего-набор без инструкции. Конечно, нам удалось разобраться и собрать все в нормально функционирующую конструкцию. Кстати, стоит отметить, что микросервисная структура - это не всегда именно про контейнеры. Просто иногда такая упаковка максимально “экологична”. А завершить сегодняшний пост хотелось бы такой прикольной переозвучкой, которая попалась нам на YouTube: - А у вас есть kubernetes? - Да, конечно, ну как у всех! Как полагается. - А зачем? - Ну как это зачем? Это же… И дальше, что логично, бедный разочарованный DevOps идет просто биться головой о стену.

Как баг может стать фичей и может ли вообще? В среде разработчиков ходит такая поговорка как “это не баг, а фича!, вообще-то, это фича!”. Однако мнения тут все-таки расходятся. Постараемся разобраться, что к чему и вспомним наш собственный опыт. Начнем с того, что сама фича - это уникальная особенность кода/программы/сервера, которая служит той самой “изюминкой”. А вот баг - то, что вставляет палки в колеса техническому процессу и мешает нормальной работоспособности. С базой познакомились. Давайте двигаться дальше. Удивительно, но допущенные разработчиками ошибки могут…сыграть в плюс! Самый известный кейс - это игра StarCraft от Blizzard. Дело было в том, что Муталиск (моб Зергов) должен был останавливаться в определенный момент, однако вместо этого постоянно двигался вперед, под атаки. И этот баг оживил StarCraft и понравился настолько сильно, что был оставлен и превратился в ту самую фичу, интегрированную во 2 часть игры специально. Если говорить про опыт InfoScale, то мы предпочитаем действовать по отработанной схеме: увидели/заметили баг - исправили его, чтобы потом тот не навернул весь сервер. А то пока ты сидишь и думаешь, “хороший” это баг или плохой, тот уже вполне может успеть сделать свое “черное” дело. А с фичами мы работаем уже отдельно. Так надежнее!

Завариваем чай, берем печеньки и двигаем DevOps-юмор в массы! Давайте будем честными: IT-тружеников привыкли воспринимать как людей довольно скучных, замкнутых и только и делающих, что говорящих непонятными для всех вокруг словами. Но ведь это совсем не так! У наших DevOps-ов, например, есть, над чем посмеяться. Конечно, юмор и мемы у них свои, локальные. Но сегодня и мы попробуем немного ими проникнуться и посмеяться вместе. Про дейлики А еще летучки, пятиминутки…все это одно и то же! Именно на них DevOps собираются, трут виски, заваривают утренний кофе (и, желательно, побольше) и приступают к разбору полетов: кто что вчера сделал и какие задачи поставлены на сегодня. И тут два варианта: либо DevOps выглядит как та замученная лиса из мема и все вопросы касательно его работоспособности отпадают, либо придется выкручивать на максимум свои актерские способности и притворяться, что не валял вчера весь день дурака. Или просто краснеть. Но лучше так, товарищи, не делать. И работать работать и…работать! Слышишь ор и знаешь, откуда он По факту это относится ко всем, кто так или иначе работает с кодом. И для того, чтобы визуализировать то мироощущение, которое накатывает периодически на DevOps-тружеников, стоит просто вспомнить того милейшего визжащего в отчаянии котенка, завирусившегося на просторах сети совсем недавно. Причин может быть куча: пятничный релиз, от которого никак не отмажешься, мутные таски от руководителей и горы претензий от разработчиков. И как, спрашивается, все это разгрести? А совсем недавно на нашем YouTube-канале вышел ролик, в котором мы вместе с нашим тим-лидом смотрим топовые DevOps мемы и разъясняем, что к чему. Смотрите по ссылке и познавайте тонкости юмора, недоступного простым смертным - youtu.be/...kdn

DevOps на страже ваших серверов 24/7 (да, и ночью тоже) Такая практика действительно имеет место быть. Ведь, сами посудите, сервера находятся в свободном доступе даже ночью. А это значит, что никогда нельзя быть уверенным, что они не навернутся именно в темное время суток. И да, если ночь у вас, то это совсем не значит, что у ваших пользователей сейчас она же. Да и про полуночных сов забывать тоже все-таки не стоит. Вот поэтому DevOps-команда и заступает всегда на дежурство. Вернее, выбирает одного не самого везучего сеньора, который на ближайшие сутки будет вынужден вооружиться внушительной дозой кофеина и заступить на пост дежурного. С рядовыми инцидентами он может разобраться и сам. А вот если ситуация серьезнее, то “письмо счастья” или обычный телефонный звонок доходят и до всей остальной команды. И тем приходится оперативно выбираться из своих теплых постелек и что-то предпринимать, чтобы все либо окончательно не рухнуло, либо как-то стабилизировалось. От вовремя принятого, верного решения будет целиком и полностью зависеть, насколько быстро восстановятся все технические процессы. Медлить в том деле нельзя. Конечно, звонок - это крайняя мера. Но уж лучше всей команде лишиться пары часиков сна, чем потом засесть на несколько дней за восстановление всего сервера.

Да пребудет с нами DevOps! А с ним за компанию - автоматизация. Именно так считает наш сеньор Иван, и вот чем он с нами поделился, когда мы задали вполне логичный вопрос “а почему?” То, что нужно не просто запомнить, а буквально вбить себе в голову: автоматизация - это не просто хорошо; это если не абсолютная панацея, то что-то очень к ней близкое. Более того, это одна из наиболее актуальных и важных черт всего современного IT-подхода. Именно автоматизация напрямую способствует тому, что на рутинные, скучные и утомительные задачи начинает тратиться минимальное количество времени. А свободное можно использовать для продумывания более креативных решений и всяческих инноваций. Ивану всегда забавно, когда руководители отказывают в дополнительной автоматизации, ссылаясь на то, сколько времени она займет. Действительно, в дедлайн в 72 часа тут не уложишься. Однако все эти временные затраты окупятся в очень и очень скором времени после запуска автоматизированных алгоритмов. И окупятся они не в 10, не в 20 и даже не в 50 раз, а во все 1000 или даже 100 000! В общем, тут определенно есть над чем подумать. Если же надумаете, то Иван со всей нашей DevOps-командой однозначно будут рады помочь.

Счастье по DevOps-ски Задумывались ли вы когда-нибудь, а чему радуется DevOps-инженер? Комфортному ортопедическому компьютерному креслу и чашечке качественного свежесваренного кофе под боком? Ответ стандартный, но вполне себе реалистичный. Однако, когда мы спросили нашего DevOps-инженера Ивана, что для него в работе представляет наибольший кайф, то получили довольно неожиданный ответ. Так вот, представим, что есть некая задача. Необходимо автоматизировать развертывание. Исходные данные - час. А нужно-то как-то оперативнее. Конечно, возможных решений тут - вагон и маленькая тележка. Например, можно собраться вместе с коллегами. Совместными усилиями все запроектировать и т.д. С первого раза редко что-то получается. И в случае с DevOps это правило тоже имеет место быть. Но вот, наконец, происходит оно - вместо изначального часа развертывание занимает…всего 10 минут! Задача со звездочкой решена. Это ли не счастье? Вот для нашего сеньора Ивана оно именно такое.

Про боли DevOps-инженера Конечно, как у любого гордого представителя IT, у DevOps-инженера больных мест много. Кака минимум - постоянная сидячая работа и онеменение в шейном отделе. Но речь сейчас немного о другом. А именно - о постановке задач. Ну, или о тех же самых инцидентах. А теперь запомним раз и навсегда: “ничего не работает!” - это не описание проблемы. Выдохнули и повторили еще раз. И запомнили короткий, но очень важный алгоритм, который сохранит нервные клетки не одному DevOps-инженеру. Обращаясь с проблемой, ответьте последовательно на ряд вопросов: Что конкретно не работает? Как это было проверено и выяснено? Что ты делал, когда обнаружил поломку? Если ненадолго притормозить и подумать, то ответить на все эти вопросы - совершенно не сложно, и вообще дело 10 минут. Не заставляйте DevOps-специалистов искать иголку в стоге сена. Итак работа не самая простая, так еще и подобные мелочи дико жрут такое ценное время. Которое, между прочим, DevOps может потратить на то, что своевременно, по горячим следам, решить возникшую проблему.

Несовершенный код или “мы упали, но аккуратно” Многие наши клиенты удивляются, когда мы прямо говорим, что писать сразу идеальный код - это не слишком рационально. Если выражаться мягко. Но почему же мы так считаем? Элементарно. Мы реалисты, а потому прекрасно понимаем, что абсолютно совершенного кода не существует. Любой код может упасть. И этот момент иногда бывает практически невозможно промониторить. Что действительно важно, так это подготовить подушку безопасности. То есть обставить все таким образом, что при падении сервера, поражение было минимальным. В первую очередь, для пользователей. Вспомним тот же самый Google с его знаменитым динозавром (своего рода “подушкой безопасности”), который появляется при падении сервера или при слабом сигнале. Такая фича гораздо меньше бесит пользователей, чем красное предупреждение об ошибке на весь экран. Это же касается и метрик, и лок. Разумеется, если метрики не пишутся, то это проблема большая и серьезная. Но - для IT-отдела, который должен быть в состоянии решить все в рабочем порядке. Не кладя при этом весь сервер.

Работа над ошибками: в чем и как мы ошибались и что не допустим больше никогда? Часть 3 Сегодняшняя история - special контент от нашего DevOps-инженера Ивана. Из первых уст, как говорится. Суть проста - еще в самом начале своего пути, до работы в InfoScale, он вместе с товарищем ломал продакшн. Происходило это до смешного тупо и просто: точку с запятой где-то забудешь, а валидатор это не увидит; то просто некорректная конфигурация выйдет. Издержки производства - одним словом. Но было больно. Первыми всегда ругалось руководство. Затем технические директора. И далее по нарастающей. Но есть такая прекрасная фраза как “Неважно, сколько раз ты упал. Важно — сколько раз ты поднялся”. Согласитесь - как будто четко про сервера. И хоть инциденты всегда были тем еще стрессом, но, как поделился с нами Иван, искать решения для них всегда было…увлекательно. И иногда в процессе находились такие решения, которые могли внезапно оптимизировать весь сервер от начала и до конца. То есть “улучшайзинг” выкручивался даже не на 100, а на все 200%. В общем, специалисты у нас работают креативные. И умеющие найти выход из любой ситуации! P.S Возникновения которых мы, разумеется, стараемся просто-напросто не допускать.