В “далеком” августе 2008-ого 2 парней на конференции в Торонто впервые в истории произнесли слово DevOps. Сейчас этой практике почти 10 лет, и я думаю, самое время поговорить о том, во что превратилась эта культура, и что нас ждет дальше. Но сейчас чуть-чуть назад во времени.
Давным давно, когда главными инструментами сисадминов были bash и python, а общение между разработчиками и инженерами велось через системы управления проектами и тикеты, обновление приложений было неприятным и долгим процессом. Разработчики писали новый код, тестировщики прогоняли по нему тесты, а инженеры в ограниченный промежуток времени, именуемый maintenance window, выкатывали новую версию. Код не всегда работал как задумано, инженеры ругали разработчиков, разработчики ругали инженеров, проблема не на нашей стороне, вот это вот все. В последствии люди стали кое-как автоматизировать свою работу, кто-то делал это на коленке, изобретая велосипед, кто-то написал и стал продавать Hudson (папа Jenkins’а).
По сути, что тогда, что сейчас, проблема одна - разработчики просто хотят писать код, а инженеры просто хотят, чтобы оно работало. В итоге люди поняли, что так “оно” работать не может, и придется “дружить”. Так и появился DevOps - культура, в которой инженеры и разработчики работают вместе.
Как бывает с каждый новшеством, DevOps столкнулся с большой проблемой - его никто не понимал.
Во-первых, ИТшники обнаружили, что они “уже” делают DevOps - у них есть автотесты, CI (между прочим, этот термин впервые появился в 1991-году), автоматизированное развертывание и даже управление конфигурациями (самый старая тулза, насколько я знаю - CFEngine, релиз которого состоялся аж в 1993-ем, и им до сих пор пользуется IBM).
Во-вторых, управленцы решили, что DevOps это отдельная роль (и это, пожалуй, самое главное заблуждение), и стали искать под это дело DevOps инженеров, с 5+ лет опыта. Это было на минуточку в 2009-ом, когда культуре еще не исполнилось и года.
Однако были и те, кто понимал суть DevOps (это в основном были те, кто его и придумал) и пытались его адаптировать.
С тех пор особо ничего не изменилось, люди до сих пор ищут silver bullet, “правильный” DevOps, а на сайтах поиска работы до сих пор присутствуют вакансии DevOps инженер. Но это, как я думаю, нормально и врядли изменится.
Первое и самое главное, что люди усвоили, адаптируя DevOps, это совместное использование практик разработки и системного администрирования в работе друг друга. Это, на мой взгляд, главное достижение.
Разработчики впервые начали смотреть на приложение с точки зрения админа - оно может ломаться, оно будет ломаться, и надо написать его так, чтобы оно “чинилось” как можно скорее (SRE) . Инженеры же пытались придумать, как можно описать настройку сервера в одном файлe (и желательно не в Bash скрипте), чтобы не ходить руками на каждый сервер (Infra-as-Code), да чтоб его еще и протестировать можно было.
Давным давно, когда главными инструментами сисадминов были bash и python, а общение между разработчиками и инженерами велось через системы управления проектами и тикеты, обновление приложений было неприятным и долгим процессом. Разработчики писали новый код, тестировщики прогоняли по нему тесты, а инженеры в ограниченный промежуток времени, именуемый maintenance window, выкатывали новую версию. Код не всегда работал как задумано, инженеры ругали разработчиков, разработчики ругали инженеров, проблема не на нашей стороне, вот это вот все. В последствии люди стали кое-как автоматизировать свою работу, кто-то делал это на коленке, изобретая велосипед, кто-то написал и стал продавать Hudson (папа Jenkins’а).
По сути, что тогда, что сейчас, проблема одна - разработчики просто хотят писать код, а инженеры просто хотят, чтобы оно работало. В итоге люди поняли, что так “оно” работать не может, и придется “дружить”. Так и появился DevOps - культура, в которой инженеры и разработчики работают вместе.
Как бывает с каждый новшеством, DevOps столкнулся с большой проблемой - его никто не понимал.
Во-первых, ИТшники обнаружили, что они “уже” делают DevOps - у них есть автотесты, CI (между прочим, этот термин впервые появился в 1991-году), автоматизированное развертывание и даже управление конфигурациями (самый старая тулза, насколько я знаю - CFEngine, релиз которого состоялся аж в 1993-ем, и им до сих пор пользуется IBM).
Во-вторых, управленцы решили, что DevOps это отдельная роль (и это, пожалуй, самое главное заблуждение), и стали искать под это дело DevOps инженеров, с 5+ лет опыта. Это было на минуточку в 2009-ом, когда культуре еще не исполнилось и года.
Однако были и те, кто понимал суть DevOps (это в основном были те, кто его и придумал) и пытались его адаптировать.
С тех пор особо ничего не изменилось, люди до сих пор ищут silver bullet, “правильный” DevOps, а на сайтах поиска работы до сих пор присутствуют вакансии DevOps инженер. Но это, как я думаю, нормально и врядли изменится.
Первое и самое главное, что люди усвоили, адаптируя DevOps, это совместное использование практик разработки и системного администрирования в работе друг друга. Это, на мой взгляд, главное достижение.
Разработчики впервые начали смотреть на приложение с точки зрения админа - оно может ломаться, оно будет ломаться, и надо написать его так, чтобы оно “чинилось” как можно скорее (SRE) . Инженеры же пытались придумать, как можно описать настройку сервера в одном файлe (и желательно не в Bash скрипте), чтобы не ходить руками на каждый сервер (Infra-as-Code), да чтоб его еще и протестировать можно было.
Все это требовалось, чтобы превратить 3 отдела (Dev, QA, Ops) в одну структуру, работающую как часы. Вдохновленные историей про 10 релизов в день, люди стали придумывать разные методы достижения этой цели. Выделились 2 аспекта: технологический и организационный.
Что касалось техники, то тут все было более менее просто. И у инженеров, и у разработчиков уже были необходимые инструменты для работы, оставалось только их “подружить”. Так, например, инженеры стали хранить свои скрипты в системе контроля версий, а разработчики отправлять логи не локально, а на централизованное хранилище (как logstash). Стали совершенствовать мониторинг приложений с помощью отправки метрик, выделять конфиги приложения и держать их в отдельном месте, добавлять в приложения API для проверки работоспособности.
Микросервисная архитектура позволила упростить релизы и ликвидировать центральную точку отказа. CI/CD автоматизировал полную цепочку от коммита до развертывания в staging (а иногда и в prod). Amazon и прочие облачные провайдеры становился все популярнее, вышел Docker, а вслед за ним Kubernetes и Mesos, популярные сервисы для разработки Jira, Slack, Github и т.д. стали теснее интегрироваться друг с другом - медленно, но верно, наступала технологическая ИТ утопия.
С организационной точки зрения дела шли чуть похуже. Не смотря на то, что DevOps подразумевал совместную работу 3 разных ролей, большинство контор формировало отдельные группы DevOps - специалистов, отвечающих за весь спектр DevOps инструментов.
Такой подход не только не помогал, но и мешал: главной целью DevOps было уничтожить так называемые “silo” - роли с ограниченным доступом и зоной ответственности. Хуже всего было то, что разработка и эксплуатация не всегда могли “синхронизироваться” из-за разных методов управления проектами. Если разработка была проактивной и пыталась “доставить” определенный функционал за “спринт”, то Ops оставался реакционным и реагировал на входящие тикеты от разработки, по сути превратившись в helpdesk для разработчиков.
Что касалось техники, то тут все было более менее просто. И у инженеров, и у разработчиков уже были необходимые инструменты для работы, оставалось только их “подружить”. Так, например, инженеры стали хранить свои скрипты в системе контроля версий, а разработчики отправлять логи не локально, а на централизованное хранилище (как logstash). Стали совершенствовать мониторинг приложений с помощью отправки метрик, выделять конфиги приложения и держать их в отдельном месте, добавлять в приложения API для проверки работоспособности.
Микросервисная архитектура позволила упростить релизы и ликвидировать центральную точку отказа. CI/CD автоматизировал полную цепочку от коммита до развертывания в staging (а иногда и в prod). Amazon и прочие облачные провайдеры становился все популярнее, вышел Docker, а вслед за ним Kubernetes и Mesos, популярные сервисы для разработки Jira, Slack, Github и т.д. стали теснее интегрироваться друг с другом - медленно, но верно, наступала технологическая ИТ утопия.
С организационной точки зрения дела шли чуть похуже. Не смотря на то, что DevOps подразумевал совместную работу 3 разных ролей, большинство контор формировало отдельные группы DevOps - специалистов, отвечающих за весь спектр DevOps инструментов.
Такой подход не только не помогал, но и мешал: главной целью DevOps было уничтожить так называемые “silo” - роли с ограниченным доступом и зоной ответственности. Хуже всего было то, что разработка и эксплуатация не всегда могли “синхронизироваться” из-за разных методов управления проектами. Если разработка была проактивной и пыталась “доставить” определенный функционал за “спринт”, то Ops оставался реакционным и реагировал на входящие тикеты от разработки, по сути превратившись в helpdesk для разработчиков.
Софт доставлялся все быстрее. Аппетиты бизнеса росли, и если “хорошие” топ-менеджеры (насколько топ-менеджеры могут быть хорошими) стали использовать возросшую производительность для занятия своей ниши на рынке раньше конкурентов, а освободившиеся ресурсы разработчиков выделить на R&D или другие проекты, интересные самим разработчикам, то “плохие” (читай почти все) стали радостно резать расходы, оставляя минимальное количество людей для работы над проектом, используя освободившийся бюджет под маркетинг и продажи.
DevOps несомненно помог многим проектам, но его развитие совпало с общемировым повышением спроса на ИТшников. Люди не из сферы ИТ решили попробовать что-то новенькое (а тут на радость пришел JS с миллионом фреймворков), и на рынок пришло очень и очень много разработчиков с 3 месяцами работы. Чуть позже, с развитием DevOps направления, на рынок пришло такое же количество DevOps инженеров, которые знают, как написать Ansible playbook, но не знают, что такое load average.
Как я уже сказал, это ожидаемо, естественно и даже хорошо. Но проблемы, которые были у DevOps (точнее у людей, которые его пытались применять) никуда не ушли. Люди считают, что у них DevOps, потому что они проводят много встреч, а новому человеку выдают ноутбук с предустановленными IDE и Slack. Другие считают, что у них DevOps, поскольку они используют Kubernetes. У третьих, потому что разработчики имеют root доступ на серверы.
Лучше всего все беды DevOps, сам того не замечая, описал Дмитрий Столяров из Flant (https://youtu.be/CgCLPYJRxbU). “Если вкратце, мы занимаемся DevOps’ом. Давайте по-простому, внедряем Kubernetes.”
И никто не спрашивает, а нужен ли клиенту Кубер в принципе, если у них админ никак не сделает удобную морду для развертывания разработчикам, а разрабы никак не начнут отправлять метрики приложения в мониторинг.
В чем-то сетевик-пессимист прав. Качество кода упало. Некачественный код все чаще попадает в production. Но виновата ли в этом культура?
Обвинять DevOps в том, что код резко стал плохим, это как винить поп-музыку за то, что у нас есть Ольга Бузова и “Розовое вино”.
У нас (у ИТшников в целом) есть очень много проблем, которые нам надо решить, чтобы делать свою работу хорошо. Никакие системы, тулзы, провайдеры и DevOps с Agile не помогут, пока мы сами не поймем природу проблемы и найдем в себе силы с ней бороться.
В будущем все у нас будет хорошо. Но об этом я напишу чуть позже.
DevOps несомненно помог многим проектам, но его развитие совпало с общемировым повышением спроса на ИТшников. Люди не из сферы ИТ решили попробовать что-то новенькое (а тут на радость пришел JS с миллионом фреймворков), и на рынок пришло очень и очень много разработчиков с 3 месяцами работы. Чуть позже, с развитием DevOps направления, на рынок пришло такое же количество DevOps инженеров, которые знают, как написать Ansible playbook, но не знают, что такое load average.
Как я уже сказал, это ожидаемо, естественно и даже хорошо. Но проблемы, которые были у DevOps (точнее у людей, которые его пытались применять) никуда не ушли. Люди считают, что у них DevOps, потому что они проводят много встреч, а новому человеку выдают ноутбук с предустановленными IDE и Slack. Другие считают, что у них DevOps, поскольку они используют Kubernetes. У третьих, потому что разработчики имеют root доступ на серверы.
Лучше всего все беды DevOps, сам того не замечая, описал Дмитрий Столяров из Flant (https://youtu.be/CgCLPYJRxbU). “Если вкратце, мы занимаемся DevOps’ом. Давайте по-простому, внедряем Kubernetes.”
И никто не спрашивает, а нужен ли клиенту Кубер в принципе, если у них админ никак не сделает удобную морду для развертывания разработчикам, а разрабы никак не начнут отправлять метрики приложения в мониторинг.
В чем-то сетевик-пессимист прав. Качество кода упало. Некачественный код все чаще попадает в production. Но виновата ли в этом культура?
Обвинять DevOps в том, что код резко стал плохим, это как винить поп-музыку за то, что у нас есть Ольга Бузова и “Розовое вино”.
У нас (у ИТшников в целом) есть очень много проблем, которые нам надо решить, чтобы делать свою работу хорошо. Никакие системы, тулзы, провайдеры и DevOps с Agile не помогут, пока мы сами не поймем природу проблемы и найдем в себе силы с ней бороться.
В будущем все у нас будет хорошо. Но об этом я напишу чуть позже.
YouTube
Наш опыт с Kubernetes в небольших проектах (Флант, RootConf 2017)
Доклад Дмитрия Столярова, технического директора компании «Флант» (https://flant.ru/), на конференции RootConf, проходившей в рамках фестиваля РИТ++ 2017 (6 июня 2017 г.). Посвящён устройству и основным возможностями Kubernetes и практике использования этой…
Между делом, хочу наконец научиться пользоваться голосованием в Телеграм. Давайте вместе протестируем. Про что больше писать?
🤖 - больше про технику
🤡 - больше про процессы и практики
👽 - больше про прочее
🤖 - больше про технику
🤡 - больше про процессы и практики
👽 - больше про прочее
Это тестовая голосовалка, ну и поможет узнать свою аудиторию получше. Буду ли я ей следовать и как, пока не могу сказать.
Удалось потрогать портал обучения от LinkedIn. Ценник у него такой же, как у Pluralsight, и меньше, чем у LinuxAcademy.
Из плюсов - огромный выбор курсов, в том числе и не связанных с ИТ. Дизайн, маркетинг, вот это вот все.
Из минусов - в основе обучения лежат видеолекции с небольшими лабами, которые качаются и делаются локально. Закрепленность знаний проверяется небольшими тестами, не дающими понимания, что полученная информация закреплена на практике. Но этим же страдает и Pluralsight.
Правда, открыл курс основ по веб-разработке и дизайну (совсем нулевый), и в первой же секции идет дубовое пояснение основ HTML, CSS и, простите, JavaScript.
Особенно раздражает, когда лектор с сияющими глазами говорит: “Да, это выглядит довольно сложно, но, поверьте, это очень легко!”
Вот… честно, не люблю таких преподавателей. Их мотивация понятна - им нужно стимулировать все больше новичков входить в сферу ИТ, но так не делается.
В последнем голосовании, люди 10 раз нажали на инопланетянина. Я позволю себе предположить, чтобы вы либо имеете косвенное отношение к ИТ, либо вам интереснее, когда я пишу про свои приключения с газовыми компаниями.
Но на всякий случай, если вы однажды захотите начать (или продолжить) карьеру в ИТ: неважно, какое направление вы выберете, будь то дизайн, разработка или системная инженерия - ИТ это НЕ легко.
Как и любая другая интеллектуальная деятельность, ИТ требует навыков и знаний, которые необходимо приобрести, прежде чем начать бороздить просторы рекрутинговых сайтов. Это не значит, что нужно бросать все и поступать в МГТИ имени Баумана, но придется инвестировать в себя деньги и время.
Любой, кто скажет вам “ИТ это легко” - лжец и подлец. “Гоните его, насмехайтесь над ним.”
Из плюсов - огромный выбор курсов, в том числе и не связанных с ИТ. Дизайн, маркетинг, вот это вот все.
Из минусов - в основе обучения лежат видеолекции с небольшими лабами, которые качаются и делаются локально. Закрепленность знаний проверяется небольшими тестами, не дающими понимания, что полученная информация закреплена на практике. Но этим же страдает и Pluralsight.
Правда, открыл курс основ по веб-разработке и дизайну (совсем нулевый), и в первой же секции идет дубовое пояснение основ HTML, CSS и, простите, JavaScript.
Особенно раздражает, когда лектор с сияющими глазами говорит: “Да, это выглядит довольно сложно, но, поверьте, это очень легко!”
Вот… честно, не люблю таких преподавателей. Их мотивация понятна - им нужно стимулировать все больше новичков входить в сферу ИТ, но так не делается.
В последнем голосовании, люди 10 раз нажали на инопланетянина. Я позволю себе предположить, чтобы вы либо имеете косвенное отношение к ИТ, либо вам интереснее, когда я пишу про свои приключения с газовыми компаниями.
Но на всякий случай, если вы однажды захотите начать (или продолжить) карьеру в ИТ: неважно, какое направление вы выберете, будь то дизайн, разработка или системная инженерия - ИТ это НЕ легко.
Как и любая другая интеллектуальная деятельность, ИТ требует навыков и знаний, которые необходимо приобрести, прежде чем начать бороздить просторы рекрутинговых сайтов. Это не значит, что нужно бросать все и поступать в МГТИ имени Баумана, но придется инвестировать в себя деньги и время.
Любой, кто скажет вам “ИТ это легко” - лжец и подлец. “Гоните его, насмехайтесь над ним.”
Продолжаю играть с голосовалками. Опрос для ИТ спецов и всех, кто с ними связан.
Какого рода вы ИТ спец (разработка или администрирование)
- 😃 - если вы по Microsoft (Windows Server, Powershell, OctopusDeploy, etc).
- 😍 - если по Linux (RedHat, Ubuntu, bash, etc).
- 😳 - если оба.
Какого рода вы ИТ спец (разработка или администрирование)
- 😃 - если вы по Microsoft (Windows Server, Powershell, OctopusDeploy, etc).
- 😍 - если по Linux (RedHat, Ubuntu, bash, etc).
- 😳 - если оба.
Яндекс индексирует документы в Google Drive. Если у вас там что-то важное - убедитесь, что это хорошо спрятано за настройками приватности. Яндекс вроде это дело исправил, но береженого Бог бережет.
Ну и помним, что хранить пароли и явки где-то в облаке у Гугла - absolutely haram.
Ну и помним, что хранить пароли и явки где-то в облаке у Гугла - absolutely haram.
Теперь, когда мы поговорили о том, к чему пришел DevOps в наши дни, самое время написать о том, что полезного (помимо уже сказанного) он нам принес.
Компании стали применять DevOps по-разному. Те, кто уже использовал популярные framework’и Agile, например Scrum, поставили инженеров в “продуктовые” команды. То есть у вас есть команда - разработчики, тестировщики, инженеры. Поскольку Scrum подразумевает кросс-функциональные команды, на выходе мы имеем разрабов, которые немножко сисадмины, и сисадминов, которые немножко разрабы.
В целом неплохо, и такая модель хорошо работает, правда у нее есть и свои недостатки. Например, когда у вас продуктовая команда как вещь-в-себе, она пилит проект так, как ей удобно. Платформа, ОС, язык программирования, DevOps tools - все выбирается самой командой и строго под ее нужды. Если у вас много продуктовых команд, то вы получаете потрясающий бардак и зоопарк, где команда А уже сидит в Кубере с этими вашим докером, а команда Б все еще делает golden AMI в AWS во время релиза новой версии приложения. Сравнить KPI (а топы очень любят KPI) таких команд тяжело, поэтому проверить эффективность той или иной команды становится тем еще приключением.
Другие конторы, чаще всего крупный сектор с headcount в 5000+ человек и миллиардным оборотом, стали делать отделы - отдел FrontEnd разработки (их может быть много), Baсkend разработки (тоже может быть много), отдел инфраструктуры и, простите, отдел DevOps.
Вроде silo - все сидят в своих уголках и что-то там делают. Взаимодействие уже не такое шустрое, люди могут сидеть в разных офисах, если не городах или странах - сложно просто подойти и поговорить ртом. Но и такой подход имеет право на жизнь, и вот почему.
Когда вы инженер в DevOps отделе, вы “поддерживаете” разработчиков. В ваших интересах, чтобы разрабы спокойно и без лишних проблем выкатывали новый код в production, а вы, если что, быстро его откатите обратно. Если вы инженер инфраструктурного отдела (допустим у вас в 2018-ом до сих пор свой ЦОД), то вам нужно, чтобы серверы и сеть работали без перебоев.
Такие потребности позволяют создать сервисно-ориентированные команды. Infra-команда не предоставляет железо - она предоставляет сервис, где каждый может “заказать” себе виртуалку. DevOps команда не предоставляет тулзы - она предоставляет сервис для управления приложениями.
Поскольку такие команды обладают бОльшей экспертизой в инструментарии, нежели сами разработчики, то они дают им один инструмент под определенную задачу, например, Puppet/Ansible/Chef для управления серверами, Terraform/Cloudformation для создания новых ресурсов, Jenkins/Teamcity для CI/CD, Github/Gitlab/GitUNameIt для хранения исходников, ну и всякие Linter’ы и прочие финтифлюшки. У разрабов особо нет выбора, и они пишут приложения, придерживаясь каких-то общих, зачастую навязанных административным ресурсом, стандартов.
Получается, что у команд вроде продукты свои, но процесс везде похожий, если не одинаковый. А бизнес любит, когда все работают одинаково (ведь так проще увольнять).
Если отбросить все фанатичные заявления DevOps энтузиастов, обе модели работают отлично, если их грамотно приготовить. Но, опять же в будущем, все будет еще круче (об этом на следующей неделе, нужно собрать все мысли воедино).
Компании стали применять DevOps по-разному. Те, кто уже использовал популярные framework’и Agile, например Scrum, поставили инженеров в “продуктовые” команды. То есть у вас есть команда - разработчики, тестировщики, инженеры. Поскольку Scrum подразумевает кросс-функциональные команды, на выходе мы имеем разрабов, которые немножко сисадмины, и сисадминов, которые немножко разрабы.
В целом неплохо, и такая модель хорошо работает, правда у нее есть и свои недостатки. Например, когда у вас продуктовая команда как вещь-в-себе, она пилит проект так, как ей удобно. Платформа, ОС, язык программирования, DevOps tools - все выбирается самой командой и строго под ее нужды. Если у вас много продуктовых команд, то вы получаете потрясающий бардак и зоопарк, где команда А уже сидит в Кубере с этими вашим докером, а команда Б все еще делает golden AMI в AWS во время релиза новой версии приложения. Сравнить KPI (а топы очень любят KPI) таких команд тяжело, поэтому проверить эффективность той или иной команды становится тем еще приключением.
Другие конторы, чаще всего крупный сектор с headcount в 5000+ человек и миллиардным оборотом, стали делать отделы - отдел FrontEnd разработки (их может быть много), Baсkend разработки (тоже может быть много), отдел инфраструктуры и, простите, отдел DevOps.
Вроде silo - все сидят в своих уголках и что-то там делают. Взаимодействие уже не такое шустрое, люди могут сидеть в разных офисах, если не городах или странах - сложно просто подойти и поговорить ртом. Но и такой подход имеет право на жизнь, и вот почему.
Когда вы инженер в DevOps отделе, вы “поддерживаете” разработчиков. В ваших интересах, чтобы разрабы спокойно и без лишних проблем выкатывали новый код в production, а вы, если что, быстро его откатите обратно. Если вы инженер инфраструктурного отдела (допустим у вас в 2018-ом до сих пор свой ЦОД), то вам нужно, чтобы серверы и сеть работали без перебоев.
Такие потребности позволяют создать сервисно-ориентированные команды. Infra-команда не предоставляет железо - она предоставляет сервис, где каждый может “заказать” себе виртуалку. DevOps команда не предоставляет тулзы - она предоставляет сервис для управления приложениями.
Поскольку такие команды обладают бОльшей экспертизой в инструментарии, нежели сами разработчики, то они дают им один инструмент под определенную задачу, например, Puppet/Ansible/Chef для управления серверами, Terraform/Cloudformation для создания новых ресурсов, Jenkins/Teamcity для CI/CD, Github/Gitlab/GitUNameIt для хранения исходников, ну и всякие Linter’ы и прочие финтифлюшки. У разрабов особо нет выбора, и они пишут приложения, придерживаясь каких-то общих, зачастую навязанных административным ресурсом, стандартов.
Получается, что у команд вроде продукты свои, но процесс везде похожий, если не одинаковый. А бизнес любит, когда все работают одинаково (ведь так проще увольнять).
Если отбросить все фанатичные заявления DevOps энтузиастов, обе модели работают отлично, если их грамотно приготовить. Но, опять же в будущем, все будет еще круче (об этом на следующей неделе, нужно собрать все мысли воедино).
Прежде чем говорить про будущее, давайте еще раз вспомним прошлое. Чего хотят разработчики? Писать код. Чего хотят инженеры? Чтобы оно работало.
Ни тем, ни другим не хочется мучаться с серверами, развертыванием, мониторингом и т.д. (Хотя чего это я, может и хочется). Так что же нам дают методики и технологии сегодня, и что они нам могут дать в будущем?
Неоднозначную реакцию общественности вызвала парадигма разработки serverless - якобы приложения без серверов. Если не язвить, что говорят так люди, не знающие, как устроены компьютерные программы, то можно увидеть идею за следующим.
Serverless дает возможность разрабатывать и запускать приложения без предварительной настройки платформы (будь то ОС, веб сервер или сервер приложений). Написал код - прогнал тесты - запаковал - отправил на AWS Lambda. Хочешь на Python, хочешь на Java/JavaScript, хочешь на C#. Та же Lambda вкупе с другими managed сервисами AWS позволяет нам писать полноценные приложения с минимумом компьютеров в обслуживании.
Вот, например, мой любимый интернет магазин плюшевых хомячков. Написали статичный сайт, положили его в S3. Нажали на нем кнопочку “Добавить в корзину”, делается API вызов на Lambda через API Gateway. Lambda отработала, и вы видите цифру “1” напротив вашей корзины. Нажали “Заказать” - отработало. “Оплатить” - отработало. Несколько маленьких программ, выполняющих свою работу, небольшой сайт c JavaScript, S3, чтобы держать там ваш сайтик, и какое-нибудь хранилище - для пользовательских данных, товаров и прочего. Ни одного сервера под непосредственным управлением. Красота.
Далеко не все приложения сегодня могут действовать по-похожему принципу. Автоматизированные банковские системы, ERP/CRM системы и прочие до такого не скоро дойдут. Большие компании тоже - уж слишком много денег и времени вбухано на текущие разработки.
Тем не менее, начало положено. Кто-то сразу смекнул, что из этого можно сделать, кто-то не понял, но на всякий случай “заорал” и написал про NoOps, кто-то поморщился и пошел дальше админить свой сервер Ubuntu. Ну или кластер Kubernetes (кому как нравится).
С другой стороны управление инфраструктурой все больше отодвигается, давая дорогу к управлению приложениями. Немало сил приложил к этому сам Kubernetes, который может расширяться сам, без сторонней помощи инженерных групп. К нему уже придумали Helm - пакетный менеджер для приложений Kubernetes (аналог Universe для DC/OS). Если так дальше пойдет, то кроме Кубера ничего и знать не нужно будет.
Не отстает от прогресса и сам Amazon. Сервис Fargate, который позволяет развертывать Docker приложения на ECS/EKS кластеры без надобности управлять теми самими кластерами, лишает нас необходимости думать о “железной” части. К приложению легко цепляется ELB/ALB/NLB, что дает нам какой-никакой Service Discovery. Просто прелесть.
Что нас ждет дальше? Docker будет потихоньку превращаться из контейнера в своеобразную очень легкую виртуальную машину со своим state, что навсегда уничтожит границы между контейнерной и гипервизорной виртуализацией. Serverless будет находить своих поклонников среди маленьких стартапов, где не хотят тратиться на инженеров-инфраструктурщиков. Архитекторы решений потихоньку переобуются в архитекторов систем, и будут проектировать приложения вместо инфраструктур. Сисадмины будут мониторить и логгировать приложения, а не серверы. Железячники и сетевики, конечно, никуда не денутся (кто-то же сидит в ЦОДах Амазона, Гугла и Микрософта), но количество предложений на рынке труда уменьшится.
А мы с вами будем сидеть на Безусловном Базовом Доходе, потому что наша работа будет не нужна. Имея необходимые средства к существованию, мы посвятим себя науке, искусству и творчеству, пока искусственный интеллект и роботы за нас пишут код, собирают и обслуживают оборудование. Бизнес будет заказывать приложения “голосом” через voice recognition, а бездушная железяка будет их создавать.
Тем и спасемся.
Ни тем, ни другим не хочется мучаться с серверами, развертыванием, мониторингом и т.д. (Хотя чего это я, может и хочется). Так что же нам дают методики и технологии сегодня, и что они нам могут дать в будущем?
Неоднозначную реакцию общественности вызвала парадигма разработки serverless - якобы приложения без серверов. Если не язвить, что говорят так люди, не знающие, как устроены компьютерные программы, то можно увидеть идею за следующим.
Serverless дает возможность разрабатывать и запускать приложения без предварительной настройки платформы (будь то ОС, веб сервер или сервер приложений). Написал код - прогнал тесты - запаковал - отправил на AWS Lambda. Хочешь на Python, хочешь на Java/JavaScript, хочешь на C#. Та же Lambda вкупе с другими managed сервисами AWS позволяет нам писать полноценные приложения с минимумом компьютеров в обслуживании.
Вот, например, мой любимый интернет магазин плюшевых хомячков. Написали статичный сайт, положили его в S3. Нажали на нем кнопочку “Добавить в корзину”, делается API вызов на Lambda через API Gateway. Lambda отработала, и вы видите цифру “1” напротив вашей корзины. Нажали “Заказать” - отработало. “Оплатить” - отработало. Несколько маленьких программ, выполняющих свою работу, небольшой сайт c JavaScript, S3, чтобы держать там ваш сайтик, и какое-нибудь хранилище - для пользовательских данных, товаров и прочего. Ни одного сервера под непосредственным управлением. Красота.
Далеко не все приложения сегодня могут действовать по-похожему принципу. Автоматизированные банковские системы, ERP/CRM системы и прочие до такого не скоро дойдут. Большие компании тоже - уж слишком много денег и времени вбухано на текущие разработки.
Тем не менее, начало положено. Кто-то сразу смекнул, что из этого можно сделать, кто-то не понял, но на всякий случай “заорал” и написал про NoOps, кто-то поморщился и пошел дальше админить свой сервер Ubuntu. Ну или кластер Kubernetes (кому как нравится).
С другой стороны управление инфраструктурой все больше отодвигается, давая дорогу к управлению приложениями. Немало сил приложил к этому сам Kubernetes, который может расширяться сам, без сторонней помощи инженерных групп. К нему уже придумали Helm - пакетный менеджер для приложений Kubernetes (аналог Universe для DC/OS). Если так дальше пойдет, то кроме Кубера ничего и знать не нужно будет.
Не отстает от прогресса и сам Amazon. Сервис Fargate, который позволяет развертывать Docker приложения на ECS/EKS кластеры без надобности управлять теми самими кластерами, лишает нас необходимости думать о “железной” части. К приложению легко цепляется ELB/ALB/NLB, что дает нам какой-никакой Service Discovery. Просто прелесть.
Что нас ждет дальше? Docker будет потихоньку превращаться из контейнера в своеобразную очень легкую виртуальную машину со своим state, что навсегда уничтожит границы между контейнерной и гипервизорной виртуализацией. Serverless будет находить своих поклонников среди маленьких стартапов, где не хотят тратиться на инженеров-инфраструктурщиков. Архитекторы решений потихоньку переобуются в архитекторов систем, и будут проектировать приложения вместо инфраструктур. Сисадмины будут мониторить и логгировать приложения, а не серверы. Железячники и сетевики, конечно, никуда не денутся (кто-то же сидит в ЦОДах Амазона, Гугла и Микрософта), но количество предложений на рынке труда уменьшится.
А мы с вами будем сидеть на Безусловном Базовом Доходе, потому что наша работа будет не нужна. Имея необходимые средства к существованию, мы посвятим себя науке, искусству и творчеству, пока искусственный интеллект и роботы за нас пишут код, собирают и обслуживают оборудование. Бизнес будет заказывать приложения “голосом” через voice recognition, а бездушная железяка будет их создавать.
Тем и спасемся.
❤1
Посвящается Валере и @DevOpsOnCall. Контора решила не отставать от прогрессивных компаний и внедряет дежурства.
Говоря о будущем, нельзя не упомянуть всеми любимую (и нелюбимую) криптуху.
Как некоторые из вас знают, помимо основной работы у меня есть сторонний проект, связанный с автоматизированной торговлей на криптовалютных биржах. Я стараюсь о нем писать редко, так как он не имеет прямого отношения к моему каналу, а в проекте я использую навыки, полученные на основной работе (и крайне редко - наоборот).
Поскольку проект запустился в открытом бета режиме с мая 2018-ого, мы получили рост пользователей выше прогнозируемого и были вынуждены переехать на AWS раньше срока (старый ДЦ не давал возможностей для расширения). Пока мы не начали «агрессивный» «маркетинг» пользователи приходили через сарафанное радио, а значит были достаточно опытными (большая часть была в крипте еще до 2013-ого). Было у нас порядка 200 человек, 100 с лишним из которых были в группе «пожизненно бесплатно» - эти товарищи первыми рискнули вложить свои средства в торговлю на GSMG, тем самым показав нам свое доверие и завоевав наше. Этим ребята стали «адвокатами»: они продвигают робота среди своих тусовочек и помогают новичкам в общих чатах.
Но надо как-то зарабатывать деньги, и мои партнеры по бизнесу начали сотрудничать со всякими голландскими криптосообществами, чтобы привлечь побольше людей. Что же из этого получилось? Как и раньше, в этих ваших интернетах все еще огромное количество «dumb money» (глупых денег). Люди, вложившие в крипту на волне общего «хайпа», ожидают бешеного роста и прибылей в 100-150% в первые несколько дней. Среди таких самый стандартный вопрос - почему робот работает полчаса и до сих пор не заработал на Ламбо.
Хуже того, люди абсолютно не умеют (или не хотят) читать и отправляют деньги на наш кошелек, не зная о его предназначении (средства на нем «оплачивают» работу платформы, а не участвуют в торгах). Люди отправляют от 5 до 10 эфиров (от 2000 до 4000 $), а потом слезно просят их обратно. «Я отправил, а потом прочитал руководство, верните, пожалуйста!»
Все это раздражает, ведь от людей, которые реально часть своих сбережений держат в крипте (нет лучше способа спрятать их от налоговой), ожидаешь какой-никакой финансовой и технической грамотности.
Не помогает “бизнесу” и испортившие репутацию торговых платформ финансовые пирамиды, например BitConnect, и платформы, не сумевшие вовремя подстроиться под изменившийся рынок и обвинившие в этом биржи (TraderDaddy, по сути наш основной конкурент). Из-за таких кадров на 10 человек приходится 2-3 гения, утверждающих, что мы лжецы и подлецы и хотим забрать все ваши деньги (Хотя наша платфома технически на это неспособна).
Ловел (тот самый друг хорват, посадивший меня на этот веселый криптокорабль), относится к ним с состраданием. Какой бы ни был человек, умный или глупый, клевый или занудный - он все еще наш клиент, и если он не заработает, то и мы не заработаем (наша бизнес-модель заключается в “сжигании” суммы, равной 25% от прибыли с торговой пары из “топлива” пользователя, пользователь “платит” за робота, отправляя средства на наш кошелек, тем самым пополняя “топливо”).
И хоть я верю, что крипта и блокчейн лежат в основе некоей финансовой и технологической революции, которая “вот-вот скоро совсем скоро” наступит (хорошо если через 10 лет), но “глупые деньги” не раз подкинут нам (и не только нам) палок в колеса, обогащая негодяев и разрушая имидж криптовалют.
Как некоторые из вас знают, помимо основной работы у меня есть сторонний проект, связанный с автоматизированной торговлей на криптовалютных биржах. Я стараюсь о нем писать редко, так как он не имеет прямого отношения к моему каналу, а в проекте я использую навыки, полученные на основной работе (и крайне редко - наоборот).
Поскольку проект запустился в открытом бета режиме с мая 2018-ого, мы получили рост пользователей выше прогнозируемого и были вынуждены переехать на AWS раньше срока (старый ДЦ не давал возможностей для расширения). Пока мы не начали «агрессивный» «маркетинг» пользователи приходили через сарафанное радио, а значит были достаточно опытными (большая часть была в крипте еще до 2013-ого). Было у нас порядка 200 человек, 100 с лишним из которых были в группе «пожизненно бесплатно» - эти товарищи первыми рискнули вложить свои средства в торговлю на GSMG, тем самым показав нам свое доверие и завоевав наше. Этим ребята стали «адвокатами»: они продвигают робота среди своих тусовочек и помогают новичкам в общих чатах.
Но надо как-то зарабатывать деньги, и мои партнеры по бизнесу начали сотрудничать со всякими голландскими криптосообществами, чтобы привлечь побольше людей. Что же из этого получилось? Как и раньше, в этих ваших интернетах все еще огромное количество «dumb money» (глупых денег). Люди, вложившие в крипту на волне общего «хайпа», ожидают бешеного роста и прибылей в 100-150% в первые несколько дней. Среди таких самый стандартный вопрос - почему робот работает полчаса и до сих пор не заработал на Ламбо.
Хуже того, люди абсолютно не умеют (или не хотят) читать и отправляют деньги на наш кошелек, не зная о его предназначении (средства на нем «оплачивают» работу платформы, а не участвуют в торгах). Люди отправляют от 5 до 10 эфиров (от 2000 до 4000 $), а потом слезно просят их обратно. «Я отправил, а потом прочитал руководство, верните, пожалуйста!»
Все это раздражает, ведь от людей, которые реально часть своих сбережений держат в крипте (нет лучше способа спрятать их от налоговой), ожидаешь какой-никакой финансовой и технической грамотности.
Не помогает “бизнесу” и испортившие репутацию торговых платформ финансовые пирамиды, например BitConnect, и платформы, не сумевшие вовремя подстроиться под изменившийся рынок и обвинившие в этом биржи (TraderDaddy, по сути наш основной конкурент). Из-за таких кадров на 10 человек приходится 2-3 гения, утверждающих, что мы лжецы и подлецы и хотим забрать все ваши деньги (Хотя наша платфома технически на это неспособна).
Ловел (тот самый друг хорват, посадивший меня на этот веселый криптокорабль), относится к ним с состраданием. Какой бы ни был человек, умный или глупый, клевый или занудный - он все еще наш клиент, и если он не заработает, то и мы не заработаем (наша бизнес-модель заключается в “сжигании” суммы, равной 25% от прибыли с торговой пары из “топлива” пользователя, пользователь “платит” за робота, отправляя средства на наш кошелек, тем самым пополняя “топливо”).
И хоть я верю, что крипта и блокчейн лежат в основе некоей финансовой и технологической революции, которая “вот-вот скоро совсем скоро” наступит (хорошо если через 10 лет), но “глупые деньги” не раз подкинут нам (и не только нам) палок в колеса, обогащая негодяев и разрушая имидж криптовалют.
👍1
Очередной опросик. С платформами и пожеланиями людей опредилились, теперь интересно, как вы связаны с криптухой.
Без холиваров типа “биток против альтов” и прочего.
Вопрос простой - есть ли у вас крипта?
🤖 - есть.
😳 - нет.
Без холиваров типа “биток против альтов” и прочего.
Вопрос простой - есть ли у вас крипта?
🤖 - есть.
😳 - нет.
Раз тут аж больше 20 человек, то милости прошу к нашему шалашу: https://gsmg.io
За помощью сюда: https://help.gsmg.io
Телеграм тусовочка тут: https://t.me/GSMG_Bot (говорим по-английски).
За помощью сюда: https://help.gsmg.io
Телеграм тусовочка тут: https://t.me/GSMG_Bot (говорим по-английски).
Telegram
GSMG - Community & support group
Community and Support Channel for GSMG Automated Crypto Trade Bot
👍1
У Скрама (один из фреймворков Agile) есть одна такая процедура, называется “Daily Scrum” (или Daily StandUp).
Заключается в простой встрече членов команды, где каждый рассказывает о достижениях вчерашнего дня и делах на “сегодня”. Простенькая встреча, которая должна всех друг с другом синхронизировать, ну и можно поднять животрепещущие вопросы.
Название “стендап” исходит от того, что на этой встрече все, как вы догадались, стоят. На этой встрече обязательно надо стоять (иначе у вас неправильный Скрам), потому что так встреча протекает быстрее. Дескать, стоя люди устают, хотят поскорее закончить и разбежаться по своим делам, а когда сидишь на встрече, тебе удобно, и очень много времени тратится на болтовню.
По мне, так это самое большое заблуждение. Да, люди устают, но они не начинают от этого выдавать информацию сжато. А если у вас на “стендапе” 10 человек (считается, что каждый говорит не дольше минуты или двух), то последний в списке задолбается настолько, что выдаст пару слов, лишь бы поскорее посадить свою задницу на удобный, мягкий, ортопедический стул.
На выходе мы имеем встречу, которую все судорожно ненавидят и не хотят на нее идти.
Скрам требует определенной дисциплины и самоконтроля, он прекрасно подходит для маленький команд со свежим продуктом, будущее которого не ясно. В свою очередь, он совершенно не подходит для больших монолитных проектов и инженерных команд, особенно работающих реакционно, по входящим “тикетам”.
В интернете очень много споров на тему правильно и неправильно приготовленного Скрама, о важности роли Скрам-мастера и кому это роль нужно давать, но я не встречал обсуждений утренних стендапов. (Хотя тех, кто их не любит, я встречаю часто).
Больше всего мне понравился подход, который реализовали в одной смежной команде: у них стендапов нет, но каждое утро, во время когда должен быть стендап, все члены команды пишут небольшое письмо со своими “делами” своему тимлиду. Тимлид эти письма мельком читает и в случае конфликтных или потенциально конфликтных ситуаций назначает предметные встречи. Времени затрачивается минимум, переговорку искать не нужно, кто работает удаленно, не должен сломя голову бежать за микрофоном. Утопия.
Заключается в простой встрече членов команды, где каждый рассказывает о достижениях вчерашнего дня и делах на “сегодня”. Простенькая встреча, которая должна всех друг с другом синхронизировать, ну и можно поднять животрепещущие вопросы.
Название “стендап” исходит от того, что на этой встрече все, как вы догадались, стоят. На этой встрече обязательно надо стоять (иначе у вас неправильный Скрам), потому что так встреча протекает быстрее. Дескать, стоя люди устают, хотят поскорее закончить и разбежаться по своим делам, а когда сидишь на встрече, тебе удобно, и очень много времени тратится на болтовню.
По мне, так это самое большое заблуждение. Да, люди устают, но они не начинают от этого выдавать информацию сжато. А если у вас на “стендапе” 10 человек (считается, что каждый говорит не дольше минуты или двух), то последний в списке задолбается настолько, что выдаст пару слов, лишь бы поскорее посадить свою задницу на удобный, мягкий, ортопедический стул.
На выходе мы имеем встречу, которую все судорожно ненавидят и не хотят на нее идти.
Скрам требует определенной дисциплины и самоконтроля, он прекрасно подходит для маленький команд со свежим продуктом, будущее которого не ясно. В свою очередь, он совершенно не подходит для больших монолитных проектов и инженерных команд, особенно работающих реакционно, по входящим “тикетам”.
В интернете очень много споров на тему правильно и неправильно приготовленного Скрама, о важности роли Скрам-мастера и кому это роль нужно давать, но я не встречал обсуждений утренних стендапов. (Хотя тех, кто их не любит, я встречаю часто).
Больше всего мне понравился подход, который реализовали в одной смежной команде: у них стендапов нет, но каждое утро, во время когда должен быть стендап, все члены команды пишут небольшое письмо со своими “делами” своему тимлиду. Тимлид эти письма мельком читает и в случае конфликтных или потенциально конфликтных ситуаций назначает предметные встречи. Времени затрачивается минимум, переговорку искать не нужно, кто работает удаленно, не должен сломя голову бежать за микрофоном. Утопия.
Как только мой канал стал становиться все популярнее (я считаю успехом уже то, что меня читают больше 100 человек), я стал следить за количеством подписчиков, шо за этими вашими бетховенами.
Цифра растет - эйфория, радость, тщеславие.
Цифра падает - самоанализ, паника, «я слишком часто пишу», «я слишком редко пишу», «я пишу херню».
Если продолжить корреляцию с ценой биткоина, то понятно - канал вырос слишком быстро (особенно если учесть, что в продвижение не вложено ни копейки), и теперь количество «корректируется».
Я знаю, что мои слова могут оскорбить вас или ваших знакомых. Все ,что я здесь пишу, не является откровением, вы все это видели, читали и знаете без меня.
И пусть я очень рад, что вы со мной, я не буду «фильтровать» контент (в этом и преимущество авторского канала).
Единственная гарантия, которую я вам даю - на этом канале нет и не будет никакой рекламы. Никогда. Это не значит, что в один момент у меня не появится мысль превратить вложенные усилия в доход, но до этого еще далеко, да и монетизировать я буду через какие-нибудь онлайн курсы собственного производства (если конечно мне будет чему вас учить).
В остальном - задавайте вопросы, предлагайте идеи для контента. Я приложу все усилия, чтобы подготовить ответы на ваши вопросы (но я не могу обещать, что они вам понравятся).
Цифра растет - эйфория, радость, тщеславие.
Цифра падает - самоанализ, паника, «я слишком часто пишу», «я слишком редко пишу», «я пишу херню».
Если продолжить корреляцию с ценой биткоина, то понятно - канал вырос слишком быстро (особенно если учесть, что в продвижение не вложено ни копейки), и теперь количество «корректируется».
Я знаю, что мои слова могут оскорбить вас или ваших знакомых. Все ,что я здесь пишу, не является откровением, вы все это видели, читали и знаете без меня.
И пусть я очень рад, что вы со мной, я не буду «фильтровать» контент (в этом и преимущество авторского канала).
Единственная гарантия, которую я вам даю - на этом канале нет и не будет никакой рекламы. Никогда. Это не значит, что в один момент у меня не появится мысль превратить вложенные усилия в доход, но до этого еще далеко, да и монетизировать я буду через какие-нибудь онлайн курсы собственного производства (если конечно мне будет чему вас учить).
В остальном - задавайте вопросы, предлагайте идеи для контента. Я приложу все усилия, чтобы подготовить ответы на ваши вопросы (но я не могу обещать, что они вам понравятся).
Я не самый большой фанат киновселенной Марвел, но стараюсь ходить на все свежие фильмы. Не пасхалок ради (я в жизни ни одного комикса не прочитал, разве что “Утиных историй”, когда был совсем маленьким), а так - ради удовольствия от попкорно-жвачковой индустрии.
Марвел довольно крепко засел в киноиндустрии, денег там крутится огромное количество (не удивлюсь, если даже больше чем в индустрии комиксов), но что для меня стало “открытием”, так это их приверженность к… достоверности, если можно применить это слово к фантастическим комиксам для детей и детей-переростков.
У Марвела есть такой супергерой Тор, комиксовый вариант того самого Тора - бога грома из пантеона северных богов. Скандинавская мифология для меня тема новая и приглянулась после просмотра множества сезонов “Викингов”.
Я всегда считал, что Тор от Марвела был таким (нервным, драчливым, выпендрежным и честолюбивым), потому что так решили его нарисовать американцы. Но как только я начал чтение “Северных Богов” Нила Геймана, я открыл для себя немало прекрасного. Удивить после греческой мифологии сложно (один только Зевс, спящий со всем, что двигается, и его стервозная злющая жена Гера чего стоят), но северные мифы СМОГЛИ.
Вот просто один из многих мифов в книге. Итак, у Тора есть могучий молот Мьельнир, и в один прекрасный день его у него воруют. Тор по обыкновению решает, что это проделки его брата Локи. Когда выясняется, что это не так, Локи отправляется на поиски утраченного оружия массового поражения и находит преступника.
Украл его повелитель огров Трюм, который взамен возвращения молота домой желает жениться на богине Фрейе (вообще Фрейю все время ставят на кон, бедная женщина). Когда Локи возвращается в Асгард, товарищи устраивают совет, на котором решают отправить Трюму невесту. В качестве невесты отправляют самого Тора, предварительно одев его в женские свадебные наряды и навесив на него украшений. Дабы тот не раскрыл себя, с Тором на земли огров едет Локи, обернувшийся служанкой. Во время свадьбы, как только появляется молот, Тор срывает свое прикрытие, убивает всех огров и великанов вокруг и едет домой.
То есть еще раз - могучий Бог Грома и его брат-хитрость-во-плоти переодеваются в барышень, чтобы вернуть себе оружие, словно персонажи дешевой американской комедии с Джимом Керри в главной роли. Неудивительно, что Марвел представляет их такими же.
Не знаю, кто и под чем придумывал все эти мифы, но они прекрасны.
А еще у Тора есть колесница, в которую запряжены два козла: Ворчун и Дробила. Обожаю северную мифологию.
Марвел довольно крепко засел в киноиндустрии, денег там крутится огромное количество (не удивлюсь, если даже больше чем в индустрии комиксов), но что для меня стало “открытием”, так это их приверженность к… достоверности, если можно применить это слово к фантастическим комиксам для детей и детей-переростков.
У Марвела есть такой супергерой Тор, комиксовый вариант того самого Тора - бога грома из пантеона северных богов. Скандинавская мифология для меня тема новая и приглянулась после просмотра множества сезонов “Викингов”.
Я всегда считал, что Тор от Марвела был таким (нервным, драчливым, выпендрежным и честолюбивым), потому что так решили его нарисовать американцы. Но как только я начал чтение “Северных Богов” Нила Геймана, я открыл для себя немало прекрасного. Удивить после греческой мифологии сложно (один только Зевс, спящий со всем, что двигается, и его стервозная злющая жена Гера чего стоят), но северные мифы СМОГЛИ.
Вот просто один из многих мифов в книге. Итак, у Тора есть могучий молот Мьельнир, и в один прекрасный день его у него воруют. Тор по обыкновению решает, что это проделки его брата Локи. Когда выясняется, что это не так, Локи отправляется на поиски утраченного оружия массового поражения и находит преступника.
Украл его повелитель огров Трюм, который взамен возвращения молота домой желает жениться на богине Фрейе (вообще Фрейю все время ставят на кон, бедная женщина). Когда Локи возвращается в Асгард, товарищи устраивают совет, на котором решают отправить Трюму невесту. В качестве невесты отправляют самого Тора, предварительно одев его в женские свадебные наряды и навесив на него украшений. Дабы тот не раскрыл себя, с Тором на земли огров едет Локи, обернувшийся служанкой. Во время свадьбы, как только появляется молот, Тор срывает свое прикрытие, убивает всех огров и великанов вокруг и едет домой.
То есть еще раз - могучий Бог Грома и его брат-хитрость-во-плоти переодеваются в барышень, чтобы вернуть себе оружие, словно персонажи дешевой американской комедии с Джимом Керри в главной роли. Неудивительно, что Марвел представляет их такими же.
Не знаю, кто и под чем придумывал все эти мифы, но они прекрасны.
А еще у Тора есть колесница, в которую запряжены два козла: Ворчун и Дробила. Обожаю северную мифологию.
Поступила просьба разобрать карьерный вопрос для ИТшника - расти вверх (в менеджмент) или вширь (сеньоры, архитекторы и т.д.).
Сразу скажу, если хочется денег - однозначно вверх. Какую бы узкую специальность вы ни выбрали, менеджеры (тимлиды и все что выше) зарабатывают больше. В таком случае надо учитывать, в какой специализации вы планируете расти. Условный Senior Data Scientist будет зарабатывать больше FrontEnd TeamLead’а потому, что тренды, спрос и заинтересованность бизнеса (тимлидов пруд пруди, а толкового человека, шарящего в machine learning попробуй найди).
С другой стороны из тимлидов гораздо проще вылезти на ступень повыше (CTO - технический директор). Особенно если быть тимлидом команды, которая отвечает за core business приложения.
Другая причина, по которой люди могут пойти “наверх”, заключается в желании менять (и меняться). Человек может видеть организационные или процессные огрехи, но повлиять на них может только косвенно (чаще всего он может повлиять только на своего тимлида). Повлиять на смежные команды, не говоря уже про менеджмент повыше, не позволяет недостаток компетенций, всяких bigger picture и административного ресурса. Тебя наняли писать код и пилить приложения, так пиши код и пили приложения. Менеджеру это дается гораздо проще.
Третья причина проста и прозаична - надоедает. Надоедает писать, ломать, дебажить, тестировать, релизить и прочее. Если для вас работа не хобби (как в моем случае), то какие бы новые и веселые технологии, инструменты и фреймворки ни появились, вам все равно станет ужасно скучно. Роль менеджера немного разбавляет технологическую рутину рутиной организационной. Нужно планировать бюджет, выбивать себе вакансии, создавать для каждого подчиненного план развития, да и в целом - больше заниматься people management (где people - это люди в принципе, и не только в вашей команде).
Надо понимать, что рост в тимлиды возможен, когда у вас определенный авторитет в команде, и ваши будущие подчиненные вас уважают и вам доверяют. Без этого никак (если только не хотите потом слухов, что вы ставленник по блату да и вообще подлец), и заслужить доверие своей команды гораздо сложнее, особенно когда начинаешь джуниором, чем благословение людей сверху. Дополнительным недостатком роста вверх можно назвать постепенную потерю технических навыков: больше работы с людьми, меньше работы с машинами, а значит - не успеваете за локомотивом технического прогресса.
Что касается линейки развития как специалист, то тут все просто: джун, мидл, синьор, в некоторых конторах principal (это прям еще круче, чем сеньор). Градация повыше показывает вашу как техническую подготовленность, так и определенный кругозор и набор soft skills, например - умение договариваться или вести презентации.
Другим аспектом горизонтального роста может выступать то же желание смены обстановки или желание менять.
Например, вы работаете разрабом в backend, и вас очень не устраивает работа инженеров из эксплуатации: тикеты отрабатывают долго, приложения лежат, мониторинг орет, вот это вот все. Что можно сделать? Придти к ним на помощь (заодно наладите связь с коллегами по ту сторону баррикад). Получается тройной выигрыш - и новые вещи делаете (освоить DevOps tooling, честно скажу, дело не хитрое), и коллегам поможете, и бизнес будет доволен. Такой “переход”, даже временный, дает возможность освоить новую для себя сферу и прицениться к потенциальной работе.
Из DevOps энтузиастов - людей, которые не просто пишут код и/или помогают развертывать и обслуживать приложения, но и разрушают барьеры между “красными” и “белыми” - потом вырастают опытные консультанты и архитекторы, которые “повидали некоторое дерьмо”. За таких в Европе очень много платят.
Стоя на перепутье карьерного роста, задайте себе несколько вопросов:
- Нравится ли вам ваша работа?
- Почему вам нравится/не нравится ваша работа?
- Нравится ли вам ваш доход?
- Нравится ли вам ваша команда?
- Что бы вы хотели в ней поменять?
- Что бы вы хотели изменить в своей жизни?
Сразу скажу, если хочется денег - однозначно вверх. Какую бы узкую специальность вы ни выбрали, менеджеры (тимлиды и все что выше) зарабатывают больше. В таком случае надо учитывать, в какой специализации вы планируете расти. Условный Senior Data Scientist будет зарабатывать больше FrontEnd TeamLead’а потому, что тренды, спрос и заинтересованность бизнеса (тимлидов пруд пруди, а толкового человека, шарящего в machine learning попробуй найди).
С другой стороны из тимлидов гораздо проще вылезти на ступень повыше (CTO - технический директор). Особенно если быть тимлидом команды, которая отвечает за core business приложения.
Другая причина, по которой люди могут пойти “наверх”, заключается в желании менять (и меняться). Человек может видеть организационные или процессные огрехи, но повлиять на них может только косвенно (чаще всего он может повлиять только на своего тимлида). Повлиять на смежные команды, не говоря уже про менеджмент повыше, не позволяет недостаток компетенций, всяких bigger picture и административного ресурса. Тебя наняли писать код и пилить приложения, так пиши код и пили приложения. Менеджеру это дается гораздо проще.
Третья причина проста и прозаична - надоедает. Надоедает писать, ломать, дебажить, тестировать, релизить и прочее. Если для вас работа не хобби (как в моем случае), то какие бы новые и веселые технологии, инструменты и фреймворки ни появились, вам все равно станет ужасно скучно. Роль менеджера немного разбавляет технологическую рутину рутиной организационной. Нужно планировать бюджет, выбивать себе вакансии, создавать для каждого подчиненного план развития, да и в целом - больше заниматься people management (где people - это люди в принципе, и не только в вашей команде).
Надо понимать, что рост в тимлиды возможен, когда у вас определенный авторитет в команде, и ваши будущие подчиненные вас уважают и вам доверяют. Без этого никак (если только не хотите потом слухов, что вы ставленник по блату да и вообще подлец), и заслужить доверие своей команды гораздо сложнее, особенно когда начинаешь джуниором, чем благословение людей сверху. Дополнительным недостатком роста вверх можно назвать постепенную потерю технических навыков: больше работы с людьми, меньше работы с машинами, а значит - не успеваете за локомотивом технического прогресса.
Что касается линейки развития как специалист, то тут все просто: джун, мидл, синьор, в некоторых конторах principal (это прям еще круче, чем сеньор). Градация повыше показывает вашу как техническую подготовленность, так и определенный кругозор и набор soft skills, например - умение договариваться или вести презентации.
Другим аспектом горизонтального роста может выступать то же желание смены обстановки или желание менять.
Например, вы работаете разрабом в backend, и вас очень не устраивает работа инженеров из эксплуатации: тикеты отрабатывают долго, приложения лежат, мониторинг орет, вот это вот все. Что можно сделать? Придти к ним на помощь (заодно наладите связь с коллегами по ту сторону баррикад). Получается тройной выигрыш - и новые вещи делаете (освоить DevOps tooling, честно скажу, дело не хитрое), и коллегам поможете, и бизнес будет доволен. Такой “переход”, даже временный, дает возможность освоить новую для себя сферу и прицениться к потенциальной работе.
Из DevOps энтузиастов - людей, которые не просто пишут код и/или помогают развертывать и обслуживать приложения, но и разрушают барьеры между “красными” и “белыми” - потом вырастают опытные консультанты и архитекторы, которые “повидали некоторое дерьмо”. За таких в Европе очень много платят.
Стоя на перепутье карьерного роста, задайте себе несколько вопросов:
- Нравится ли вам ваша работа?
- Почему вам нравится/не нравится ваша работа?
- Нравится ли вам ваш доход?
- Нравится ли вам ваша команда?
- Что бы вы хотели в ней поменять?
- Что бы вы хотели изменить в своей жизни?
Еще один опрос для людей, работающих с DevOps.
Сколько вы в культуре? Именно в культуре, опыт работы с CFEngine со дня релиза не считается, общий опыт тоже.
🙃 - до года
😐 - от 1 до 3 лет
😊- от 3 до 6
😈 - от 6 и больше
Сколько вы в культуре? Именно в культуре, опыт работы с CFEngine со дня релиза не считается, общий опыт тоже.
🙃 - до года
😐 - от 1 до 3 лет
😊- от 3 до 6
😈 - от 6 и больше