Про личный бренд.
В моем понимании личный бренд состоит из:
- узнаваемость в организации
- узнаваемость в индустрии в пределах одной страны
- узнаваемость в индустрии по всему миру
У нас на слуху имена Торвальдса и Столлмана.
Многие из нас так же знают Митчелла Хашимото и Брандона Грэгга.
Мы прекрасно знаем, что это за люди, мы прекрасно к ним относимся, и мы доверяем им и тому, что они говорят.
Личный бренд может решить (но необязательно решит) следующие задачи:
- прием на работу в желаемую компанию и/или желаемую должность
- продвижение идей внутри компании или индустрии
В Нидерландах личный бренд только упростит устройство на работу. Например, когда я устраивался на должность Cloud Architect, мне, как незнакомому организации лицу, нужно было подтвердить свои знания в 3 технических собеседованиях и одном тестовом задании.
Моему коллеге, который до этого работал в Philips на такой же позиции, было достаточно одного. Его background и запись в резюме сказали за него больше, чем он сам.
Однако нам обоим необходимо проводить подробное исследование, чтобы протолкнуть наши идеи: вы помните из моих предыдущих постов, что в NL в условной команде или департаменте все равны, и задавить авторитетом не получится.
В РФ (я предполагаю) дела обстоят несколько иначе. Приди я на очередной митап DevOps Moscow, буду выглядеть для тусовочки диковинной зверушкой (если только вся тусовочка не читает этот канал), мой доклад будут прогонять, а аудитория будет слушать вполуха (что ожидаемо).
В итоге, чтобы протолкнуть что-либо, мне нужно будет раз за разом выступать с первоклассными докладами, зарабатывая очки авторитета у аудитории.
Но по мере роста доверия доклад будет уменьшаться в размере: в нем будет меньше аргументов, потому что главный аргумент - сам докладчик. Он уже все, кому надо, доказал.
Похожим образом личный бренд может развиваться и в пределах одной организации, а узнаваемость в индустрии, заработанная на конференциях и митапах, будет приятным бонусом.
Иными словами, задача инженера своими действиями показать: «Вася Пупкин - крутой инженер».
Достигать этого вы будете через превосходную работу, проактивность, исполнительность, доклады или knowledge sharing - уже вторично.
По себе могу сказать, что времена, когда можно было строить карьеру, просто занимаясь своим делом и «прокачивая» hard skills, закончились.
People marketing плотно вошел в индустрию, и если не хотите встрять на 2-3 линии поддержки до самой пенсии, придется красиво одеваться и торговать лицом.
Поверьте мне, это окупится сполна.
В моем понимании личный бренд состоит из:
- узнаваемость в организации
- узнаваемость в индустрии в пределах одной страны
- узнаваемость в индустрии по всему миру
У нас на слуху имена Торвальдса и Столлмана.
Многие из нас так же знают Митчелла Хашимото и Брандона Грэгга.
Мы прекрасно знаем, что это за люди, мы прекрасно к ним относимся, и мы доверяем им и тому, что они говорят.
Личный бренд может решить (но необязательно решит) следующие задачи:
- прием на работу в желаемую компанию и/или желаемую должность
- продвижение идей внутри компании или индустрии
В Нидерландах личный бренд только упростит устройство на работу. Например, когда я устраивался на должность Cloud Architect, мне, как незнакомому организации лицу, нужно было подтвердить свои знания в 3 технических собеседованиях и одном тестовом задании.
Моему коллеге, который до этого работал в Philips на такой же позиции, было достаточно одного. Его background и запись в резюме сказали за него больше, чем он сам.
Однако нам обоим необходимо проводить подробное исследование, чтобы протолкнуть наши идеи: вы помните из моих предыдущих постов, что в NL в условной команде или департаменте все равны, и задавить авторитетом не получится.
В РФ (я предполагаю) дела обстоят несколько иначе. Приди я на очередной митап DevOps Moscow, буду выглядеть для тусовочки диковинной зверушкой (если только вся тусовочка не читает этот канал), мой доклад будут прогонять, а аудитория будет слушать вполуха (что ожидаемо).
В итоге, чтобы протолкнуть что-либо, мне нужно будет раз за разом выступать с первоклассными докладами, зарабатывая очки авторитета у аудитории.
Но по мере роста доверия доклад будет уменьшаться в размере: в нем будет меньше аргументов, потому что главный аргумент - сам докладчик. Он уже все, кому надо, доказал.
Похожим образом личный бренд может развиваться и в пределах одной организации, а узнаваемость в индустрии, заработанная на конференциях и митапах, будет приятным бонусом.
Иными словами, задача инженера своими действиями показать: «Вася Пупкин - крутой инженер».
Достигать этого вы будете через превосходную работу, проактивность, исполнительность, доклады или knowledge sharing - уже вторично.
По себе могу сказать, что времена, когда можно было строить карьеру, просто занимаясь своим делом и «прокачивая» hard skills, закончились.
People marketing плотно вошел в индустрию, и если не хотите встрять на 2-3 линии поддержки до самой пенсии, придется красиво одеваться и торговать лицом.
Поверьте мне, это окупится сполна.
А вот и обещанный доклад с конференции в Москве.
https://www.youtube.com/watch?v=LHnOhG1BtEE
P.S. Да, звук отстает.
https://www.youtube.com/watch?v=LHnOhG1BtEE
P.S. Да, звук отстает.
YouTube
DevOpsForum 2019 l Переезд в публичное облако (на примере AWS)
Карен Товмасян, Нидерланды
NewMotion, инженер-архитектор облачных решений
3 года опыта промышленной эксплуатации AWS, обладает сертификациями AWS Certified Solutions Architect Associate, AWS Certified Developer Associate
1) Вступительная часть: AWS vs…
NewMotion, инженер-архитектор облачных решений
3 года опыта промышленной эксплуатации AWS, обладает сертификациями AWS Certified Solutions Architect Associate, AWS Certified Developer Associate
1) Вступительная часть: AWS vs…
По моему недавнему посту про аварию Я.О я получил несколько сообщений, так что вот небольшое summary и мнение.
Нет, уничтожать инфраструктуру клиента не является нормальной или стандартной практикой облачных провайдеров.
Нет, клиент не должен создавать свои продукты, опираясь на то, что провайдер услуг будет их всячески ломать.
Но между клиентом и провайдером услуг есть так называемая shared responsibility модель (за что отвечает он, а за что клиент). Провайдер никогда не будет гарантировать вам, что железо, на котором живет ваша виртуальная машина, никогда не упадет. Провайдер так же не будет гарантировать, что его сотрудники никогда не допустят ошибок.
Провайдер чаще всего прямым текстом говорит, что берет на себя задачи по эксплуатации железа, но вы (клиент) несете ответственность за резервирование и дублирование данных. Вот ЭТО как раз-таки нормально, потому что провайдер отвечает за снижение операционной нагрузки клиента за счет модели managed service’ов (и именно так он и зарабатывает деньги).
Если провайдер дает вам какие-то гарантии, т.е. “у нас никогда ничего не падает вообще” - с таким провайдером не надо иметь дел от слова совсем.
Нет, наличие собственной инфраструктуры не уменьшает риска потери данных, оно переносит риск с провайдера услуг на вас. Если доверяете себе и своим сотрудникам больше, чем сотрудникам провайдера - не пользуйтесь услугами провайдера.
Нет, это ненормально, если провайдер гарантирует 100% uptime SLA. Если он гарантирует - подробно читайте условия SLA, найдете там много интересного (например, посмотрите SLA Cloudflare).
Нет, я не являюсь сотрудником AWS или другого облачного провайдера. Я не получаю от провайдеров денег, у меня нет партнерского соглашения ни с одним из них.
Я не являюсь евангелистом или, прости Боже, influencer’ом, и если когда либо стану - вы об этом узнаете первыми (после меня и работодателя).
Я крайне критично отношусь ко всем провайдерам и настоятельно рекомендую так делать своей публике.
Если есть неотвеченные вопросы - дайте знать.
(Ушел писать про Troposphere)
Нет, уничтожать инфраструктуру клиента не является нормальной или стандартной практикой облачных провайдеров.
Нет, клиент не должен создавать свои продукты, опираясь на то, что провайдер услуг будет их всячески ломать.
Но между клиентом и провайдером услуг есть так называемая shared responsibility модель (за что отвечает он, а за что клиент). Провайдер никогда не будет гарантировать вам, что железо, на котором живет ваша виртуальная машина, никогда не упадет. Провайдер так же не будет гарантировать, что его сотрудники никогда не допустят ошибок.
Провайдер чаще всего прямым текстом говорит, что берет на себя задачи по эксплуатации железа, но вы (клиент) несете ответственность за резервирование и дублирование данных. Вот ЭТО как раз-таки нормально, потому что провайдер отвечает за снижение операционной нагрузки клиента за счет модели managed service’ов (и именно так он и зарабатывает деньги).
Если провайдер дает вам какие-то гарантии, т.е. “у нас никогда ничего не падает вообще” - с таким провайдером не надо иметь дел от слова совсем.
Нет, наличие собственной инфраструктуры не уменьшает риска потери данных, оно переносит риск с провайдера услуг на вас. Если доверяете себе и своим сотрудникам больше, чем сотрудникам провайдера - не пользуйтесь услугами провайдера.
Нет, это ненормально, если провайдер гарантирует 100% uptime SLA. Если он гарантирует - подробно читайте условия SLA, найдете там много интересного (например, посмотрите SLA Cloudflare).
Нет, я не являюсь сотрудником AWS или другого облачного провайдера. Я не получаю от провайдеров денег, у меня нет партнерского соглашения ни с одним из них.
Я не являюсь евангелистом или, прости Боже, influencer’ом, и если когда либо стану - вы об этом узнаете первыми (после меня и работодателя).
Я крайне критично отношусь ко всем провайдерам и настоятельно рекомендую так делать своей публике.
Если есть неотвеченные вопросы - дайте знать.
(Ушел писать про Troposphere)
Материал по Troposphere занимает гораздо больше времени, чем хотелось бы, но такого рода статью лучше преподнести позже, но подготовленнее.
Вот вам немного спойлеров для затравки:
«Когда Bool совсем не Bool.»
«Получаем гибкость Python и его же проблемы.»
«cfn-lint испортит вам все удовольствие.»
«Документацию пишет мизантроп-социопат.»
И много-много других подводных камней, которые я любезно собираю, чтобы выложить перед вами.
Оставайтесь на связи. ;)
Вот вам немного спойлеров для затравки:
«Когда Bool совсем не Bool.»
«Получаем гибкость Python и его же проблемы.»
«cfn-lint испортит вам все удовольствие.»
«Документацию пишет мизантроп-социопат.»
И много-много других подводных камней, которые я любезно собираю, чтобы выложить перед вами.
Оставайтесь на связи. ;)
Почему Medium и почему на английском?
Потому что работать над личным брендом нужно по всем фронтам, и так получилось, что ЦА над которой я начинаю работать не говорит по-русски. Medium же популярная платформа, только и всего.
Заменит ли Medium мой канал? Абсолютно нет, потому что Medium - мой инструмент продвижения, Телега - мое хобби.
Всякие лонгриды будут идти в Медиум (результаты исследований, не попадающие под NDA, и прочие интересные материалы), что-то по чтению не больше 2 минут - в канал.
По итогам работы с Troposphere могу сказать лишь одно: динамическая типизация - зло.
Потому что работать над личным брендом нужно по всем фронтам, и так получилось, что ЦА над которой я начинаю работать не говорит по-русски. Medium же популярная платформа, только и всего.
Заменит ли Medium мой канал? Абсолютно нет, потому что Medium - мой инструмент продвижения, Телега - мое хобби.
Всякие лонгриды будут идти в Медиум (результаты исследований, не попадающие под NDA, и прочие интересные материалы), что-то по чтению не больше 2 минут - в канал.
По итогам работы с Troposphere могу сказать лишь одно: динамическая типизация - зло.
Мой близкий друг и соратник @sonkintammio с месяц назад сподвиг меня приобрести электронную книжку.
Надо сказать, до этого я читал книги с телефона или компьютера, что приводило к уставшим глазам и плохо усвоенной информации (попробуй пойми прочитанное, когда в тебя со всех сторон нотификации стреляют).
Важным вопросом для меня был возврат инвестиций. Покупать устройство за 80 USD и класть его в полку не хотелось.
Женя в свою очередь убедил меня, что книжки я после этого буду пихать, как не в себя, и оказался прав.
С момента покупки (20ые числа апреля), я прочитал Site Reliability Engineering, Site Reliability Workbook, Systems Performance и Database Reliability Engineering.
На данный момент давлюсь Thinking: Fast and Slow (@count0ru, я смогу!), на очереди: Designing Distributed Systems.
Получается где-то по книжке в неделю (до этого была в лучшем случае одна в месяц).
Спасибо, Жека!
Надо сказать, до этого я читал книги с телефона или компьютера, что приводило к уставшим глазам и плохо усвоенной информации (попробуй пойми прочитанное, когда в тебя со всех сторон нотификации стреляют).
Важным вопросом для меня был возврат инвестиций. Покупать устройство за 80 USD и класть его в полку не хотелось.
Женя в свою очередь убедил меня, что книжки я после этого буду пихать, как не в себя, и оказался прав.
С момента покупки (20ые числа апреля), я прочитал Site Reliability Engineering, Site Reliability Workbook, Systems Performance и Database Reliability Engineering.
На данный момент давлюсь Thinking: Fast and Slow (@count0ru, я смогу!), на очереди: Designing Distributed Systems.
Получается где-то по книжке в неделю (до этого была в лучшем случае одна в месяц).
Спасибо, Жека!
Вот эта статья (https://advancedweb.hu/2019/05/28/aws_config_credentials/) воистину “ор выше гор”.
Советы в ней из разряда “мойте руки перед едой и после туалета”, что огорчает меня еще больше.
Тема аутентификации в AWS прожевана вдоль и поперек, давно рекомендуется не использовать IAM пользователей и группы, а аутентификацию и авторизацию делать через IAM роли. Для пользователей - использовать SAML и опять же заставлять их assume’ить роль. Для EC2 - Instance Profile’ы.
При этом в статье нет таких полезностей как авторизовывать операцию sts:AssumeRole через Conditions (а там тоже много вкусного, от проверки MFA до Source IP Address).
В целом статья выглядит даже не как повторение всем известных постулатов, а очередной Security 101.
При всем при этом тему можно развить! Добавить туда такие вещи как Hashicorp Vault, Secrets Manager, SSM Parameter Store и сделать из посредственной материала настоящую рафаэлку.
Советы в ней из разряда “мойте руки перед едой и после туалета”, что огорчает меня еще больше.
Тема аутентификации в AWS прожевана вдоль и поперек, давно рекомендуется не использовать IAM пользователей и группы, а аутентификацию и авторизацию делать через IAM роли. Для пользователей - использовать SAML и опять же заставлять их assume’ить роль. Для EC2 - Instance Profile’ы.
При этом в статье нет таких полезностей как авторизовывать операцию sts:AssumeRole через Conditions (а там тоже много вкусного, от проверки MFA до Source IP Address).
В целом статья выглядит даже не как повторение всем известных постулатов, а очередной Security 101.
При всем при этом тему можно развить! Добавить туда такие вещи как Hashicorp Vault, Secrets Manager, SSM Parameter Store и сделать из посредственной материала настоящую рафаэлку.
advancedweb.hu
Why AWS access and secret keys should not be in the codebase
Setting AWS.config.credentials is a bad practice. And it is also unnecessary.
То есть я отвлекся на новую статью, а за это время отвалился GCP и горит ЦОД в Москве?
Вчерашней историей навеяло.
Когда мне нужно рисовать стрелочки и квадратики с fault tolerance in mind, я спрашиваю заказчика про RPO (recovery point objective) и RTO (recovery time objective).
Кто не в курсе - это состояние системы к моменту восстановления, например как с PITR в СУБД (RPO), и время восстановления рабочего состояния системы, с момента оповещения до момента восстановления (RTO).
Если заказчик не знает таких аббревиатур, то разговор становится чуть длиннее.
Я предлагаю заказчику представить, что система не работает Х минут. При чем не в стиле «представьте, что сервер лежит Х минут», а именно система не работает Х минут.
Если заказчиком выступает неопытный С уровень или нетехнический контингент, я преддагаю заказчику представить, что он не может (здесь используется контекст) загрузить главную страницу в течение 20 секунд (или документ, или картиночку с котиками - любой контекст подойдет). Если заказчик говорит, что ему «норм», цифра увеличивается до тех пор, пока заказчик не начинает ерзать на стуле.
В тот момент, когда заказчик, словно раджа из «Золотой антилопы», кричит «Довольно!», я записываю RTO и перехожу к похожей пытке про RPO («Сколько заказов вы готовы безвозвратно потерять при аварии?»).
Когда эти цифры получены, можно начинать соединять квадратики и кружочки стрелочками.
Проектируя вычислительные системы в Амазоне, я отталкиваюсь от следующих степеней паранойи: отказ экземпляра ЕС2, отказ AZ, отказ какого-то сервиса в регионе, отказ целого региона. Тоже самое делается с данными.
На одном проекте, задействующем S3, я настоял на настройке cross-region replication. Объем данных был довольно большой, гарантии доступа к данными должны были быть предоставлены, но мой страх потери доступа к корзине был встречен смешками о «типичной восточно-европейской пугливости».
После марта 2017 никто уже не смеялся (угадайте в каком регионе была основная корзина?).
Когда мне нужно рисовать стрелочки и квадратики с fault tolerance in mind, я спрашиваю заказчика про RPO (recovery point objective) и RTO (recovery time objective).
Кто не в курсе - это состояние системы к моменту восстановления, например как с PITR в СУБД (RPO), и время восстановления рабочего состояния системы, с момента оповещения до момента восстановления (RTO).
Если заказчик не знает таких аббревиатур, то разговор становится чуть длиннее.
Я предлагаю заказчику представить, что система не работает Х минут. При чем не в стиле «представьте, что сервер лежит Х минут», а именно система не работает Х минут.
Если заказчиком выступает неопытный С уровень или нетехнический контингент, я преддагаю заказчику представить, что он не может (здесь используется контекст) загрузить главную страницу в течение 20 секунд (или документ, или картиночку с котиками - любой контекст подойдет). Если заказчик говорит, что ему «норм», цифра увеличивается до тех пор, пока заказчик не начинает ерзать на стуле.
В тот момент, когда заказчик, словно раджа из «Золотой антилопы», кричит «Довольно!», я записываю RTO и перехожу к похожей пытке про RPO («Сколько заказов вы готовы безвозвратно потерять при аварии?»).
Когда эти цифры получены, можно начинать соединять квадратики и кружочки стрелочками.
Проектируя вычислительные системы в Амазоне, я отталкиваюсь от следующих степеней паранойи: отказ экземпляра ЕС2, отказ AZ, отказ какого-то сервиса в регионе, отказ целого региона. Тоже самое делается с данными.
На одном проекте, задействующем S3, я настоял на настройке cross-region replication. Объем данных был довольно большой, гарантии доступа к данными должны были быть предоставлены, но мой страх потери доступа к корзине был встречен смешками о «типичной восточно-европейской пугливости».
После марта 2017 никто уже не смеялся (угадайте в каком регионе была основная корзина?).
Совсем забыл.
В Москве 18.06 пройдет AWS Dev Day.
Вы сами прекрасно знаете, про что он и для кого.
Подробности и регистрация тут: http://amp.gs/dG67
Обнимите там Стекова от меня. 😉
В Москве 18.06 пройдет AWS Dev Day.
Вы сами прекрасно знаете, про что он и для кого.
Подробности и регистрация тут: http://amp.gs/dG67
Обнимите там Стекова от меня. 😉
А вот эта история посвящается @count0ru: https://bit.ly/2WlXi9d
Medium
Response to
A story of fully automated configuration management with SSM, Lambda and Fargate
Я привык думать, что ИТ бардак присутствует в основном в молодых проектах и направлениях, где кучке смузихлебов без опыта доверено Принимать Решения.
Однако все не так плохо! Все гораздо хуже: http://stefanoborini.com/current-status-of-python-packaging/
Однако все не так плохо! Все гораздо хуже: http://stefanoborini.com/current-status-of-python-packaging/
Fly, Crash, Raise Exception
Current Status of Python Packaging - 2019
In this post, I will try to explain the intricate details of python packaging. I spent the best part of my evenings in the past two months to gather as much information as possible about the problem, the current solutions, what is legacy and what is not.
Миша задал один интересный вопрос. Цитата (орфография и грамматика сохранена): “Мне вот интересно. Бытиё определяет сознание или наоборот? В плане почему вокруг пхпшников всё всратое обычно? Потому что они пишут на пхп или они пишут на пхп потому что всратые?”
Мне вспомнилась одна история, которую рассказывал коллега на обеде. Коллега работал ведущим разработчиком и делился со мной болью.
Как любое уважающее себя legacy, e-commerce система, написанная на PHP, обладала большим количеством изъянов. Проблема была, конечно же, не в том, что писали на PHP, но в том, КАК писали на PHP.
Но главная проблема была даже не в этом. Когда на работу выходили новые ребята-иностранцы (а контора, следует отметить, нанимала иностранцев, которые на голову выше местных по навыкам), они отмечали недостатки, но старый код не трогали - никто не делает рефакторинг ради рефакторинга, а процедуры по оптимизации и “очистке” кодовой базы от мусора проводились (да и до сих пор проводятся, наверное) раз в год за месяц до католического рождества.
В свою очередь “свежая кровь” хотела избежать повторения ситуации и писала код, используя другие, “правильные” конструкции и паттерны.
Боль заключалась в том, что “новый” манер написания не проходил Code Review. Заворачивали их, потому что в конторе уже был принятый некоторый “стандарт” написания систем (как вы догадались - со всеми косяками и неэффективными конструкциями), и придерживаться стоило его. “Новичкам” не удавалось протолкнуть “кошерный” способ написания систем, потому что другим, “старичкам”, было бы сложно с ним работать - они попросту не умели и не могли (не хотели?) перестроить свое мышление.
Совсем как в эксперименте с обезьянами, бананом и холодной водой: “Здесь так принято.”
Мне вспомнилась одна история, которую рассказывал коллега на обеде. Коллега работал ведущим разработчиком и делился со мной болью.
Как любое уважающее себя legacy, e-commerce система, написанная на PHP, обладала большим количеством изъянов. Проблема была, конечно же, не в том, что писали на PHP, но в том, КАК писали на PHP.
Но главная проблема была даже не в этом. Когда на работу выходили новые ребята-иностранцы (а контора, следует отметить, нанимала иностранцев, которые на голову выше местных по навыкам), они отмечали недостатки, но старый код не трогали - никто не делает рефакторинг ради рефакторинга, а процедуры по оптимизации и “очистке” кодовой базы от мусора проводились (да и до сих пор проводятся, наверное) раз в год за месяц до католического рождества.
В свою очередь “свежая кровь” хотела избежать повторения ситуации и писала код, используя другие, “правильные” конструкции и паттерны.
Боль заключалась в том, что “новый” манер написания не проходил Code Review. Заворачивали их, потому что в конторе уже был принятый некоторый “стандарт” написания систем (как вы догадались - со всеми косяками и неэффективными конструкциями), и придерживаться стоило его. “Новичкам” не удавалось протолкнуть “кошерный” способ написания систем, потому что другим, “старичкам”, было бы сложно с ним работать - они попросту не умели и не могли (не хотели?) перестроить свое мышление.
Совсем как в эксперименте с обезьянами, бананом и холодной водой: “Здесь так принято.”
Как-то я пообещал @raxwunter начать серию блогов про AWS IAM.
Мой шкурный интерес - я устал читать одни и те же вопросы в @AWS_ru. Ну и в интернетах либо “детский” уровень, либо ссылки на курсы.
Держите первую главу глубокого погружения в IAM. Будет все, от базовых терминов до как закрывать доступ к корзине S3 по выходным и много всего прочего и интересного.
https://bit.ly/2LaDq77
Мой шкурный интерес - я устал читать одни и те же вопросы в @AWS_ru. Ну и в интернетах либо “детский” уровень, либо ссылки на курсы.
Держите первую главу глубокого погружения в IAM. Будет все, от базовых терминов до как закрывать доступ к корзине S3 по выходным и много всего прочего и интересного.
https://bit.ly/2LaDq77
Medium
AWS IAM Deep Dive. Chapter 1: Essentials
So I’ve been looking over internets if there are any blog posts or series related to the internals of AWS IAM. Quite a surprise: there are…
Продолжаем копаться в IAM, но все по базовым вещам, таким как пользователи, группы, роли и политики: https://bit.ly/2RKbVTj
Если заметили ошибку или несоответствие, кидайте камни мне в ЛС.
Если заметили ошибку или несоответствие, кидайте камни мне в ЛС.
Medium
AWS IAM Deep Dive. Chapter 2: Users, Groups, Roles, Policies
Second article in my IAM Deep Dive series
Коллеги, @stekov_me продолжает организовывать для вас годные встречи-посиделки.
«Я к вам с прекрасной новостью! 4 июля, в 19:00 мы проводим очередной meetup от сообщества AWS_RU!
Темы докладов: от настоящих Архитекторов!
1) "AWS IOT. Быстрое (но не очень) решение."
Федотов Андрей, Борисенко Петр. Synergy team.
2) «Как выжимать облака» Андрей Ивахненко. Антиплагиат.ру
Ну и конечно же секретный доклад от инженеров AWS!
Трансляция будет, пицца будет, и еще несколько сюрпризов!
Адрес:
г.Москва, пр. Андропова, дом 18, корп. 2
«Райффайзенбанк»
Так как мы идем в гости в банк очень просят для СБ,
ФИО для пропусков, название компании и email.
Данные для пропусков шлите на aws_meetup@stekov.ru»
«Я к вам с прекрасной новостью! 4 июля, в 19:00 мы проводим очередной meetup от сообщества AWS_RU!
Темы докладов: от настоящих Архитекторов!
1) "AWS IOT. Быстрое (но не очень) решение."
Федотов Андрей, Борисенко Петр. Synergy team.
2) «Как выжимать облака» Андрей Ивахненко. Антиплагиат.ру
Ну и конечно же секретный доклад от инженеров AWS!
Трансляция будет, пицца будет, и еще несколько сюрпризов!
Адрес:
г.Москва, пр. Андропова, дом 18, корп. 2
«Райффайзенбанк»
Так как мы идем в гости в банк очень просят для СБ,
ФИО для пропусков, название компании и email.
Данные для пропусков шлите на aws_meetup@stekov.ru»
Я предпочитаю не выделываться, когда происходит какая-то авария у крупного поставщика.
Во-первых у меня нет полного контекста, во-вторых я не знаю, сделал бы я лучше.
Однако случившиеся на этой и прошлой неделе отказы вызывают у меня вселенскую тоску.
Ну вот посудите сами. Cloudflare - наш поставщик CDN для GSMG.io (и как оказалось для биржи Bittrex, с которой мы работаем). Я получил уведомление от мониторинга, что бот не может подключиться к бирже, попытался зайти на администраторский интерфейс, не могу попасть на web UI.
Столько веб сайтов были клиентами Cloudflare, что мой коллега, видя 502 практически на каждой странице, которую пытался открыть, невольно спросил: “А не у нас ли это проблемы с интернетом?”.
Починили относительно быстро (всего-то 27 минут), дерьмо случается, живем дальше.
Что меня задело, так это пробка для постмортема. А именно причина: “This CPU spike was caused by a bad software deploy that was rolled back.”
Окей. С вашим SLA 100% (почитайте их ToU, там много интересного), вы по идее израсходовали error budget на той неделе. Что там SRE Book говорит по этому поводу?
Второй момент - bad software deployment. Не bad software, не bug in the software, нет. Плохое, мать его за ногу, развертывание. Лучше б написали software related и потом оправдывались, как так получилось.
И вот знаете, не хочу ныть. Будущее (и настоящее) мне нравится, куда мы катимся и идем - мне тоже нравится, но низкое качество всего на свете уже малость… надоело.
Ну то есть - у меня рабочая машина, РАЗУМЕЕТСЯ Macbook Pro 2018 15 дюймов, топовая линейка и прочие понты. Машина наградила меня сломавшимся правым динамиком, оранжевыми пятнами на дисплее и залипающим пробелом. И судя по отзывам я не один такой.
Современный веб кишит багами. Просто откройте любимую страницу и консоль разработчика.
Про degraded performance, случающийся каждый день у неисчислимого числа сервисов, я и говорить не хочу.
И на фоне всего этого мрака, я продолжаю мрачно охреневать от Амазона.
Кто с ним работает, в курсе - каждая дока каждого сервиса постоянно кричит: “Дублируй! Резервируй! Оно упадет, отвечаю! Используй больше AZ, мамой клянусь отвалюсь!!!”
И что напрягает - не падает. Я уже и не могу вспомнить событий с момента отвала S3, когда у Амазона что-то громко падало.
Напрягает не то, что я боюсь накаркать, а то что бизнес, уставший от вечных аварий по дурости, глупости или еще чего, плюнет и пойдет к поставщику, который не падает.
И все мы будем хоститься на Амазоне, хотим того или нет.
Во-первых у меня нет полного контекста, во-вторых я не знаю, сделал бы я лучше.
Однако случившиеся на этой и прошлой неделе отказы вызывают у меня вселенскую тоску.
Ну вот посудите сами. Cloudflare - наш поставщик CDN для GSMG.io (и как оказалось для биржи Bittrex, с которой мы работаем). Я получил уведомление от мониторинга, что бот не может подключиться к бирже, попытался зайти на администраторский интерфейс, не могу попасть на web UI.
Столько веб сайтов были клиентами Cloudflare, что мой коллега, видя 502 практически на каждой странице, которую пытался открыть, невольно спросил: “А не у нас ли это проблемы с интернетом?”.
Починили относительно быстро (всего-то 27 минут), дерьмо случается, живем дальше.
Что меня задело, так это пробка для постмортема. А именно причина: “This CPU spike was caused by a bad software deploy that was rolled back.”
Окей. С вашим SLA 100% (почитайте их ToU, там много интересного), вы по идее израсходовали error budget на той неделе. Что там SRE Book говорит по этому поводу?
Второй момент - bad software deployment. Не bad software, не bug in the software, нет. Плохое, мать его за ногу, развертывание. Лучше б написали software related и потом оправдывались, как так получилось.
И вот знаете, не хочу ныть. Будущее (и настоящее) мне нравится, куда мы катимся и идем - мне тоже нравится, но низкое качество всего на свете уже малость… надоело.
Ну то есть - у меня рабочая машина, РАЗУМЕЕТСЯ Macbook Pro 2018 15 дюймов, топовая линейка и прочие понты. Машина наградила меня сломавшимся правым динамиком, оранжевыми пятнами на дисплее и залипающим пробелом. И судя по отзывам я не один такой.
Современный веб кишит багами. Просто откройте любимую страницу и консоль разработчика.
Про degraded performance, случающийся каждый день у неисчислимого числа сервисов, я и говорить не хочу.
И на фоне всего этого мрака, я продолжаю мрачно охреневать от Амазона.
Кто с ним работает, в курсе - каждая дока каждого сервиса постоянно кричит: “Дублируй! Резервируй! Оно упадет, отвечаю! Используй больше AZ, мамой клянусь отвалюсь!!!”
И что напрягает - не падает. Я уже и не могу вспомнить событий с момента отвала S3, когда у Амазона что-то громко падало.
Напрягает не то, что я боюсь накаркать, а то что бизнес, уставший от вечных аварий по дурости, глупости или еще чего, плюнет и пойдет к поставщику, который не падает.
И все мы будем хоститься на Амазоне, хотим того или нет.