ДевОпс с 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, то мы предпочитаем действовать по отработанной схеме: увидели/заметили баг - исправили его, чтобы потом тот не навернул весь сервер. А то пока ты сидишь и думаешь, “хороший” это баг или плохой, тот уже вполне может успеть сделать свое “черное” дело. А с фичами мы работаем уже отдельно. Так надежнее!