This media is not supported in your browser
VIEW IN TELEGRAM
Роботы-доставщики привозят не только еду из Лавки, но иногда что-то неожиданное — например, тикер YDEX на Московскую биржу.
Это означает, что Яндекс — вновь публичная компания, акции которой свободно торгуются на бирже. Это важное событие для всей компании! Настоящий праздник!
Больше деталей можно прочитать на специальной страничке про тикер YDEX, а я просто хочу поздравить всех причастных с этим праздником ;)
#новости
Это означает, что Яндекс — вновь публичная компания, акции которой свободно торгуются на бирже. Это важное событие для всей компании! Настоящий праздник!
Больше деталей можно прочитать на специальной страничке про тикер YDEX, а я просто хочу поздравить всех причастных с этим праздником ;)
#новости
Я уже писал, что люди — это главное и именно люди — тот самый бесценный человеческий капитал в Яндексе, двигающий компанию вперед.
Яндексоиды — не только профессиональные специалисты, но и люди с очень разными интересами и хобби. В прошлом году я собирал список социальных сетей яндексоидов в этушке (платформа для блогов внутри Яндекса), но наружу этим списком я не делился, хотя бОльшая часть из собранных каналов — публичные.
Мои коллеги не сидели сложа руки и собрали каналы яндексоидов в телеграммовскую папку «Пашем-пишем».
Теперь можно в один клик подписаться на всю папку (70+ каналов!) или на ее часть. На мой взгляд, проще вначале подписаться на всю папку, а потом оставить в подписках только интересные для вас каналы.
P.S. В комментах к этому посту можно и нужно шарить ссылки на свои каналы — источник новых открытий и вдохновения ;)
#яндекс
Яндексоиды — не только профессиональные специалисты, но и люди с очень разными интересами и хобби. В прошлом году я собирал список социальных сетей яндексоидов в этушке (платформа для блогов внутри Яндекса), но наружу этим списком я не делился, хотя бОльшая часть из собранных каналов — публичные.
Мои коллеги не сидели сложа руки и собрали каналы яндексоидов в телеграммовскую папку «Пашем-пишем».
Теперь можно в один клик подписаться на всю папку (70+ каналов!) или на ее часть. На мой взгляд, проще вначале подписаться на всю папку, а потом оставить в подписках только интересные для вас каналы.
P.S. В комментах к этому посту можно и нужно шарить ссылки на свои каналы — источник новых открытий и вдохновения ;)
#яндекс
Если сотрудники должны уменьшать головную боль своего руководителя, то что должен делать руководитель?
Руководитель должен тратить время на задачи, которые не могут выполнить сотрудники. Это его первоочередная задача и добавленная стоимость.
Но часто руководители остаются разработчиками с нагрузкой руководства. Они забирают себе неинтересные задачи, оставляя команде самое вкусное. Это тормозит развитие как руководителя, так и сотрудников. Руководитель вечно занят, но свою роль не выполняет.
Чтобы можно было сделегировать задачи, нужно растить компетенции в команде.
Освобождайте время для стратегических задач вида:
- подготовки новых проектов и зон ответственности;
- разработки технологической стратегии;
- роста и позиционирования команды;
- внедрения DORA метрики :)
#руководство
Руководитель должен тратить время на задачи, которые не могут выполнить сотрудники. Это его первоочередная задача и добавленная стоимость.
Но часто руководители остаются разработчиками с нагрузкой руководства. Они забирают себе неинтересные задачи, оставляя команде самое вкусное. Это тормозит развитие как руководителя, так и сотрудников. Руководитель вечно занят, но свою роль не выполняет.
Чтобы можно было сделегировать задачи, нужно растить компетенции в команде.
Освобождайте время для стратегических задач вида:
- подготовки новых проектов и зон ответственности;
- разработки технологической стратегии;
- роста и позиционирования команды;
- внедрения DORA метрики :)
#руководство
Ко мне, как ментору, часто приходят младшие специалисты за волшебной пилюлей для успешного продвижения по карьерной лестнице.
Я помогаю подумать о задачах, составляю план развития и помогаю декомпозировать его на составляющие. Но условие успеха одно — много работать.
После такого откровения больше половины младших специалистов предпочитают искать советы где-то еще и иногда за пределами нашей компании. Увы :(
Я согласен с нашим бывшим CTO, что если нет связей и нет желания идти по головам, то остается только много работать. И этот совет отлично работает для младших специалистов.
Быстрее делайте свои текущие задачи и жадно набирайте новые.
Чтобы выросла скорость, нужно растить свою эффективность, а для этого:
- нужно внимательно слушать советы во время codereview;
- не сидеть сложа руки, если основная задача застопорилась;
- узнавать как работает проект;
- и т.д.
Фактически вы просто ускоряете свою личную релизную трубу:
1. Быстрее шипите типовые задачи в продакшен.
2. Руководитель дает вам все больше задач.
3. В итоге вы делаете все более разнообразные задачи.
4. Опыт и экспертиза накапливаются.
И как результат — неизбежно становитесь опытным разработчиком или "мидлом".
Поэтому, если вы — младший специалист, то не мучайте руководителя составлением индивидуального плана развития, а просто фигачьте :)
#карьера
Я помогаю подумать о задачах, составляю план развития и помогаю декомпозировать его на составляющие. Но условие успеха одно — много работать.
После такого откровения больше половины младших специалистов предпочитают искать советы где-то еще и иногда за пределами нашей компании. Увы :(
Я согласен с нашим бывшим CTO, что если нет связей и нет желания идти по головам, то остается только много работать. И этот совет отлично работает для младших специалистов.
Быстрее делайте свои текущие задачи и жадно набирайте новые.
Чтобы выросла скорость, нужно растить свою эффективность, а для этого:
- нужно внимательно слушать советы во время codereview;
- не сидеть сложа руки, если основная задача застопорилась;
- узнавать как работает проект;
- и т.д.
Фактически вы просто ускоряете свою личную релизную трубу:
1. Быстрее шипите типовые задачи в продакшен.
2. Руководитель дает вам все больше задач.
3. В итоге вы делаете все более разнообразные задачи.
4. Опыт и экспертиза накапливаются.
И как результат — неизбежно становитесь опытным разработчиком или "мидлом".
Поэтому, если вы — младший специалист, то не мучайте руководителя составлением индивидуального плана развития, а просто фигачьте :)
#карьера
Если младшему специалисту достаточно фигачить, то с более старшими специалистами такой трюк не пройдет. Делать только текущие задачи — недостаточно, нужно научиться делать другую работу.
Про грейды я рассуждаю примерно так:
- за стажером "нужен глаз да глаз" из-за отсутствия опыта промышленной разработки;
- младший умеет делать типовые задачи;
- специалист умеет проектировать компоненты, контролирует качество и стабильность своей части;
- старшие и ведущие специалисты умеют делать сложные непонятные задачи, решение которых неочевидно, новое измерение специалиста.
В работе старших специалистов я ожидаю следующего: надежности, качества решений и прозрачности деятельности.
Пункт № 1. Надежность
- ответственность за свои проекты;
- контроль над задачами в работе;
- своевременная эскалация обнаруженных рисков;
- и, конечно, снятие головной боли руководителя ;)
Важная ремарка про ответственность. Это не только про стабильность и качество сервисов. Это про ответственность в более широком смысле — держать свое слово, быть честным и аккуратно передавать ответственность за проект на время отпусков и отсутствий.
Пункт № 2. Качество решений
- написание технических документов, которые можно использовать для межкомандного взаимодействия;
- проектирование контрактов для взаимодействия подсистем;
- внимание к мелочам и умение наводить порядок;
- умение делать не только то, что требуют, но и то, что нужно.
Функциональность новых проектов должна органически встраиваться в текущие системы, дополнять и усиливать их. Необходимо учитывать возможности и ограничения смежных подсистем и хорошо знать инфраструктуру.
И помнить, что запуск сервиса — только начало пути :)
Пункт № 3. Прозрачность
- организация и координация работы команды в случае необходимости;
- умение выделить MVP для более быстрой поставки в продакшен;
- понятный контекст работы для своей команды, руководителя и смежников.
Организация прозрачной деятельности позволит добавить спокойствия вашему руководителю и всей команде, а также убрать лишние вопросы к своей деятельности.
А рассказывать статус по проекту с нужным уровнем абстракции для разных потребителей — высочайший полет в менеджменте, к которому нужно стремиться!
Разумеется, это не конечный список навыков, ожидаемых от более старших грейдов. Но я надеюсь, что удалось раскрыть, что значит другая работа.
#карьера
Про грейды я рассуждаю примерно так:
- за стажером "нужен глаз да глаз" из-за отсутствия опыта промышленной разработки;
- младший умеет делать типовые задачи;
- специалист умеет проектировать компоненты, контролирует качество и стабильность своей части;
- старшие и ведущие специалисты умеют делать сложные непонятные задачи, решение которых неочевидно, новое измерение специалиста.
В работе старших специалистов я ожидаю следующего: надежности, качества решений и прозрачности деятельности.
Пункт № 1. Надежность
- ответственность за свои проекты;
- контроль над задачами в работе;
- своевременная эскалация обнаруженных рисков;
- и, конечно, снятие головной боли руководителя ;)
Важная ремарка про ответственность. Это не только про стабильность и качество сервисов. Это про ответственность в более широком смысле — держать свое слово, быть честным и аккуратно передавать ответственность за проект на время отпусков и отсутствий.
Пункт № 2. Качество решений
- написание технических документов, которые можно использовать для межкомандного взаимодействия;
- проектирование контрактов для взаимодействия подсистем;
- внимание к мелочам и умение наводить порядок;
- умение делать не только то, что требуют, но и то, что нужно.
Функциональность новых проектов должна органически встраиваться в текущие системы, дополнять и усиливать их. Необходимо учитывать возможности и ограничения смежных подсистем и хорошо знать инфраструктуру.
И помнить, что запуск сервиса — только начало пути :)
Пункт № 3. Прозрачность
- организация и координация работы команды в случае необходимости;
- умение выделить MVP для более быстрой поставки в продакшен;
- понятный контекст работы для своей команды, руководителя и смежников.
Организация прозрачной деятельности позволит добавить спокойствия вашему руководителю и всей команде, а также убрать лишние вопросы к своей деятельности.
А рассказывать статус по проекту с нужным уровнем абстракции для разных потребителей — высочайший полет в менеджменте, к которому нужно стремиться!
Разумеется, это не конечный список навыков, ожидаемых от более старших грейдов. Но я надеюсь, что удалось раскрыть, что значит другая работа.
#карьера
— Какова вероятность встретить на улице динозавра?
— 50%. Либо встречу, либо нет.
Яндекс. Пятница.
#яндекс
— 50%. Либо встречу, либо нет.
Яндекс. Пятница.
#яндекс
Год назад я писал заметку про то, что когда становишься руководителем, то очень многое меняется.
Разработчики, которые органически вырастают до руководителя, думают, что это просто следующая ступенька после старшего специалиста. Но это не так.
Фактически вы переходите в новую для себя область и становитесь своего рода руководителем-стажером. Т.е. вам нужно заново наращивать компетенции.
Одна из распространенных ошибок начинающих руководителей — нежелание это признавать. Потому что "ну не просто же так меня повысили до руководителя?". Но на самом деле новому ремеслу нужно учиться так же, как и программированию.
Ну если вы, конечно, хотите стать хорошим руководителем.
#руководство
Разработчики, которые органически вырастают до руководителя, думают, что это просто следующая ступенька после старшего специалиста. Но это не так.
Фактически вы переходите в новую для себя область и становитесь своего рода руководителем-стажером. Т.е. вам нужно заново наращивать компетенции.
Одна из распространенных ошибок начинающих руководителей — нежелание это признавать. Потому что "ну не просто же так меня повысили до руководителя?". Но на самом деле новому ремеслу нужно учиться так же, как и программированию.
Ну если вы, конечно, хотите стать хорошим руководителем.
#руководство
Когда я рассказываю про декомпозицию плана развития, то называю прямоугольники этой карты "кубиками".
Я визуализирую создание сервиса или процесса в виде детских кубиков. Из кубиков можно построить домик, башню или крепость. В разработке и управлении аналогичные "кубики" — это паттерны, методологии, концепции и подходы.
На менторских встречах я советую разработчикам не быть приверженцами конкретных языков программирования или библиотек. Это прикладная часть, она постоянно меняется.
Важно сосредоточиться на решениях задач, собирать удачные решения и неудачный опыт. Это ваша коробочка с "кубиками".
Я складываю в свою коробочку более абстрактные решения, менее подверженные устареванию. Приведу пример.
Нужно настроить непрерывный процесс поставки функциональности пользователям. Это высокоуровневая задача. Для ее реализации нужен механизм, который соберет релизы, запустит тесты, валидаторы, отправит уведомления.
Речь идет про Continuous Integration (CI). Существует множество систем CI: Teamcity, Jenkins, Bitbucket Pipelines, AWS CodePipeline, GitLab.
Можно изучать каждую из этих систем, чтобы понимать, как ее настроить и использовать. Но лучше разобраться, какие задачи должен решать кубик под названием "CI" и какими свойствами он должен обладать. В какой-то момент вам должно быть уже без разницы, какой CI использует ваша команда, важно, чтобы он обладал нужным набором свойств.
Если вы придете в компанию, например, в Яндекс с самописным CI, глубокие знания Teamcity не особо помогут. А правильное высокоуровневое видение всегда полезно.
#разработка
Я визуализирую создание сервиса или процесса в виде детских кубиков. Из кубиков можно построить домик, башню или крепость. В разработке и управлении аналогичные "кубики" — это паттерны, методологии, концепции и подходы.
На менторских встречах я советую разработчикам не быть приверженцами конкретных языков программирования или библиотек. Это прикладная часть, она постоянно меняется.
Важно сосредоточиться на решениях задач, собирать удачные решения и неудачный опыт. Это ваша коробочка с "кубиками".
Я складываю в свою коробочку более абстрактные решения, менее подверженные устареванию. Приведу пример.
Нужно настроить непрерывный процесс поставки функциональности пользователям. Это высокоуровневая задача. Для ее реализации нужен механизм, который соберет релизы, запустит тесты, валидаторы, отправит уведомления.
Речь идет про Continuous Integration (CI). Существует множество систем CI: Teamcity, Jenkins, Bitbucket Pipelines, AWS CodePipeline, GitLab.
Можно изучать каждую из этих систем, чтобы понимать, как ее настроить и использовать. Но лучше разобраться, какие задачи должен решать кубик под названием "CI" и какими свойствами он должен обладать. В какой-то момент вам должно быть уже без разницы, какой CI использует ваша команда, важно, чтобы он обладал нужным набором свойств.
Если вы придете в компанию, например, в Яндекс с самописным CI, глубокие знания Teamcity не особо помогут. А правильное высокоуровневое видение всегда полезно.
#разработка
В конце прошлой недели с коллегами обсуждали "тяжелую долю" руководителей.
Все новоиспеченные руководители сталкиваются с одним и тем же кризисом — ощущение деградации как специалиста. Времени на написание кода становится меньше ввиду дополнительной административной нагрузки и помощи своей команде.
Сразу скажу, что новоиспеченные руководители не деградируют, а просто перестраиваются под новый формат работы.
Давайте обсудим это чуть подробнее.
Разработчик в течение дня пишет много кода — это его основная деятельность. Руководитель пишет меньше кода, потому что еще ревьюит код команды, ходит на встречи со смежниками и занимается административной работой. Поэтому навык написания кода у разработчика будет развиваться сильнее, чем у руководителя.
В этот момент у начинающего руководителя может возникнуть страх, что он теряет навык разработки и вообще занимается "какой-то ненужной работой". Он может даже задаться вопросом: "Зачем я вообще согласился стать руководителем?"
Но стоит помнить, что снижение в одной области компенсируется ростом в другой. Руководитель меньше пишет кода, но БОЛЬШЕ его читает и видит БОЛЬШЕ различных решений. Условно, если разработчику опыт приезжает по дороге, то в руководителя опыт летит с многополосной автострады :)
Если руководителю придется писать больше кода, то поначалу он может уступать в скорости разработчикам, но через какое-то время разница в скорости написания кода нивелируется. Практика сделает свое дело.
Помимо написания кода, нужно придумать и спроектировать решение. Вот тут руководитель со своим кругозором точно будет находиться в более выигрышной позиции.
Такие размышления успокоят не всех. Поэтому я рекомендую начинающему руководителю провести эксперимент:
1. Освободить себе 1 день в календаре.
2. Выключить мессенджер.
3. Погрузиться в детали какого-то проекта.
4. Выкатить правку в тестинг.
Так можно увидеть, что страхи преувеличены, и успокоиться ;)
#руководство
Все новоиспеченные руководители сталкиваются с одним и тем же кризисом — ощущение деградации как специалиста. Времени на написание кода становится меньше ввиду дополнительной административной нагрузки и помощи своей команде.
Сразу скажу, что новоиспеченные руководители не деградируют, а просто перестраиваются под новый формат работы.
Давайте обсудим это чуть подробнее.
Разработчик в течение дня пишет много кода — это его основная деятельность. Руководитель пишет меньше кода, потому что еще ревьюит код команды, ходит на встречи со смежниками и занимается административной работой. Поэтому навык написания кода у разработчика будет развиваться сильнее, чем у руководителя.
В этот момент у начинающего руководителя может возникнуть страх, что он теряет навык разработки и вообще занимается "какой-то ненужной работой". Он может даже задаться вопросом: "Зачем я вообще согласился стать руководителем?"
Но стоит помнить, что снижение в одной области компенсируется ростом в другой. Руководитель меньше пишет кода, но БОЛЬШЕ его читает и видит БОЛЬШЕ различных решений. Условно, если разработчику опыт приезжает по дороге, то в руководителя опыт летит с многополосной автострады :)
Если руководителю придется писать больше кода, то поначалу он может уступать в скорости разработчикам, но через какое-то время разница в скорости написания кода нивелируется. Практика сделает свое дело.
Помимо написания кода, нужно придумать и спроектировать решение. Вот тут руководитель со своим кругозором точно будет находиться в более выигрышной позиции.
Такие размышления успокоят не всех. Поэтому я рекомендую начинающему руководителю провести эксперимент:
1. Освободить себе 1 день в календаре.
2. Выключить мессенджер.
3. Погрузиться в детали какого-то проекта.
4. Выкатить правку в тестинг.
Так можно увидеть, что страхи преувеличены, и успокоиться ;)
#руководство
This media is not supported in your browser
VIEW IN TELEGRAM
Сегодня мы запустили «Геоаналитику» — бесплатный инструмент для изучения потенциала районов города на основе геопривязанных данных о трафике и поисковых запросов из Яндекс Карт.
Мы считаем, что «Геоаналитика» поможет определить перспективные места для открытия точек продаж, складов и других объектов. А еще мы впервые открыто поделились уникальными на рынке данными по пешеходному и автомобильному трафикам, чтобы помогать предпринимателям лучше оценивать количество потенциальных клиентов или найти подходящие зоны для застройки и рамещения рекламы в городе.
«Геоаналитика» — это не только полезный и бесплатный сервис, но и красивый инструмент. Кликать по гексагонам на карте своего города — очень увлекательно!
#новости
Мы считаем, что «Геоаналитика» поможет определить перспективные места для открытия точек продаж, складов и других объектов. А еще мы впервые открыто поделились уникальными на рынке данными по пешеходному и автомобильному трафикам, чтобы помогать предпринимателям лучше оценивать количество потенциальных клиентов или найти подходящие зоны для застройки и рамещения рекламы в городе.
«Геоаналитика» — это не только полезный и бесплатный сервис, но и красивый инструмент. Кликать по гексагонам на карте своего города — очень увлекательно!
#новости
На первом курсе мой сосед по общежитию (6-й курс) посоветовал мне: "Вместо игр учись слепой печати. Пригодится. Потом поймешь".
Я установил соло на клавиатуре и за несколько недель научился десятипальцевому методу. Это было непросто, хотелось вернуться к привычной печати, смотреть на клавиатуру и использовать шесть пальцев. Но я заставил себя печатать вслепую.
Я принципиально не подглядывал на клавиатуру и приучал пальцы самим находить нужные клавиши. Через какое-то время произошел "фазовый переход", и я стал печатать с той же скоростью, что и раньше. А потом скорость увеличилась уже раза в 2-3.
Но самое важное, что фокус внимания переключился на то, что я делаю, а не как делаю. "Мы не служим клавиатуре. Это сервисное действие" :)
Я помню, что мои однокурсники удивлялись, когда во время печати я переставал смотреть на экран и при этом допечатывал часть текста. Я даже покрасил свою клавиатуру в однородный черный цвет без каких-либо надписей. Это оказалась самая лучшая защита от соседей в общежитии, т.к. никто не мог пользоваться такой клавиатурой.
Я настоятельно рекомендую освоить десятипальцевый метод всем тем, кто постоянно работает за компьютером. Потраченное время окупится с лихвой уже в первый год. Проверено!
P.S. Забавно, но я не знаю расположение клавиш. Если начинаю смотреть на клавиатуру, скорость печати падает. Однако когда доверяю механической памяти, все идет отлично. 🙂
#лайфхаки
Я установил соло на клавиатуре и за несколько недель научился десятипальцевому методу. Это было непросто, хотелось вернуться к привычной печати, смотреть на клавиатуру и использовать шесть пальцев. Но я заставил себя печатать вслепую.
Я принципиально не подглядывал на клавиатуру и приучал пальцы самим находить нужные клавиши. Через какое-то время произошел "фазовый переход", и я стал печатать с той же скоростью, что и раньше. А потом скорость увеличилась уже раза в 2-3.
Но самое важное, что фокус внимания переключился на то, что я делаю, а не как делаю. "Мы не служим клавиатуре. Это сервисное действие" :)
Я помню, что мои однокурсники удивлялись, когда во время печати я переставал смотреть на экран и при этом допечатывал часть текста. Я даже покрасил свою клавиатуру в однородный черный цвет без каких-либо надписей. Это оказалась самая лучшая защита от соседей в общежитии, т.к. никто не мог пользоваться такой клавиатурой.
Я настоятельно рекомендую освоить десятипальцевый метод всем тем, кто постоянно работает за компьютером. Потраченное время окупится с лихвой уже в первый год. Проверено!
P.S. Забавно, но я не знаю расположение клавиш. Если начинаю смотреть на клавиатуру, скорость печати падает. Однако когда доверяю механической памяти, все идет отлично. 🙂
#лайфхаки
Давненько не было баек. Пора это исправить! Расскажу вам, как я сломал Яндекс Карты :)
Эта история произошла, когда я стал частью команды, работающей над веб-версией Яндекс Карт, и мне доверили мой первый большой проект. Задача стояла амбициозная: добавить возможность построения маршрутов не только на автомобилях, но и на общественном транспорте.
Скажу честно, поначалу я создал нечто вроде "фабрики багов". Но спасибо нашей команде тестировщиков — пользователи об этом даже не догадывались, ведь все баги были отловлены в тестовом окружении.
Вот мы и доходим до выпуска в продакшен. Заливаю debian-пакет на прод, открываю maps.yandex.ru, а там — сюрприз: только шапка, пустота вокруг и карты как не бывало.
Паника. Откатываю, но никакого толку. Тут уже подключается мой руководитель, и вместе мы начинаем копаться в логах серверов, чтобы понять, что происходит.
Оказалось, что скрипты postinstal debian-пакетов изрядно нам подпортили жизнь. Разработали фикс, запустили его на весь кластер, и проблема ушла.
Фууух, можно выдохнуть и на свежую голову подумать, как предотвратить такое в будущем. Ведь в тестовом окружении всё было окей, а проблема всплыла только в продакшене.
Решили, что нам нужен промежуточный этап — вот и появилось окружение prestable. Сначала выкатываем сервис туда, смотрим, как работает сервис, и если всё гладко, то потом выкладываем в продакшен. И даже если что-то пойдет не так в prestable, пострадает лишь часть пользователей, а не все.
Забавно то, что ни один пользователь не написал в поддержку о сбое. И в информационном поле тишина. Может выбрал идеальное время для сбоя? Или всем показалось, что это у них временные проблемы с интернетом.
Что ни говори, а опыт оказался бесценным. И созданный prestable не раз выручал нас, спасая пользователей от неудачных релизов. Как говорится, «кто продакшен не клал, тот настоящей жизни не видал». Ошибки — часть обучения, не так ли? 🙂
#байки #инциденты
Эта история произошла, когда я стал частью команды, работающей над веб-версией Яндекс Карт, и мне доверили мой первый большой проект. Задача стояла амбициозная: добавить возможность построения маршрутов не только на автомобилях, но и на общественном транспорте.
Скажу честно, поначалу я создал нечто вроде "фабрики багов". Но спасибо нашей команде тестировщиков — пользователи об этом даже не догадывались, ведь все баги были отловлены в тестовом окружении.
Вот мы и доходим до выпуска в продакшен. Заливаю debian-пакет на прод, открываю maps.yandex.ru, а там — сюрприз: только шапка, пустота вокруг и карты как не бывало.
Паника. Откатываю, но никакого толку. Тут уже подключается мой руководитель, и вместе мы начинаем копаться в логах серверов, чтобы понять, что происходит.
Оказалось, что скрипты postinstal debian-пакетов изрядно нам подпортили жизнь. Разработали фикс, запустили его на весь кластер, и проблема ушла.
Фууух, можно выдохнуть и на свежую голову подумать, как предотвратить такое в будущем. Ведь в тестовом окружении всё было окей, а проблема всплыла только в продакшене.
Решили, что нам нужен промежуточный этап — вот и появилось окружение prestable. Сначала выкатываем сервис туда, смотрим, как работает сервис, и если всё гладко, то потом выкладываем в продакшен. И даже если что-то пойдет не так в prestable, пострадает лишь часть пользователей, а не все.
Забавно то, что ни один пользователь не написал в поддержку о сбое. И в информационном поле тишина. Может выбрал идеальное время для сбоя? Или всем показалось, что это у них временные проблемы с интернетом.
Что ни говори, а опыт оказался бесценным. И созданный prestable не раз выручал нас, спасая пользователей от неудачных релизов. Как говорится, «кто продакшен не клал, тот настоящей жизни не видал». Ошибки — часть обучения, не так ли? 🙂
#байки #инциденты
Книга — лучший подарок, особенно если это SRE. Рецепты выживания в продакшне для инженера по надежности Наташи Савенковой. Мне посчастливилось получить её от самого автора.
Эта книга — квинтэссенция опыта из жизни яндексового SRE, без лишней воды, кратко и по делу.
В инциденте с переносом строки wwax@ отреагировала быстрее, чем моя команда, из-за правильно настроенной инфраструктуры и мониторингов.
Наташа за время своей работы в Яндексе повидала множество разных инцидентов и много вкладывалась в повышение надежности как в своих сервисах, так и на уровне компании, распространяя полезные практики в этушке.
Книга — компактная и легко читается за вечер. Рекомендую её всем, кто стремится к повышению надёжности своих сервисов.
#книги #инфраструктура
Эта книга — квинтэссенция опыта из жизни яндексового SRE, без лишней воды, кратко и по делу.
В инциденте с переносом строки wwax@ отреагировала быстрее, чем моя команда, из-за правильно настроенной инфраструктуры и мониторингов.
Наташа за время своей работы в Яндексе повидала множество разных инцидентов и много вкладывалась в повышение надежности как в своих сервисах, так и на уровне компании, распространяя полезные практики в этушке.
Книга — компактная и легко читается за вечер. Рекомендую её всем, кто стремится к повышению надёжности своих сервисов.
#книги #инфраструктура
Нашел свой пост в этушке от 2012 года про измерение своей эффективности с помощью отчета "Created vs. Resolved" в Jira.
Нужно было делать так, чтобы зеленого (решенного) было больше, чем созданного (красного).
Вначале соревновался сам с собой, а потом добавил график своего руководителя для сравнения. И ужаснулся, т.к. его результат был в 2.5 раза лучше :)
Несмотря на то, что задачи никак не нормировались и метрику можно было обмануть, это помогало мне оценить свою продуктивность.
Количество решенных задач или коммитов может служить неформальной метрикой собственной эффективности.
Но, конечно, важно не только СКОЛЬКО вы решаете задач, но и КАКИЕ именно и с КАКИМ качеством.
Спустя два месяца после публикации поста я стал руководителем группы. Может совпадение, а может быть из-за того, что много фигачил.
#карьера
Нужно было делать так, чтобы зеленого (решенного) было больше, чем созданного (красного).
Вначале соревновался сам с собой, а потом добавил график своего руководителя для сравнения. И ужаснулся, т.к. его результат был в 2.5 раза лучше :)
Несмотря на то, что задачи никак не нормировались и метрику можно было обмануть, это помогало мне оценить свою продуктивность.
Количество решенных задач или коммитов может служить неформальной метрикой собственной эффективности.
Но, конечно, важно не только СКОЛЬКО вы решаете задач, но и КАКИЕ именно и с КАКИМ качеством.
Спустя два месяца после публикации поста я стал руководителем группы. Может совпадение, а может быть из-за того, что много фигачил.
#карьера
При переворачивании котлетки меняется административная структура.
Если не предпринимать дополнительных усилий, архитектура сервисов начнёт повторять организационную структуру. Это происходит естественным образом, так как в каждой структурной единице руководители имеют разные стратегии, принимают разные решения, что приводит к эволюции технических сервисов иногда даже в противоположные стороны.
Соответственно, чтобы архитектуры развивались гармонично, нужно либо выстраивать гармоничные зоны ответственности, либо вкладывать дополнительные ресурсы на поддержание общей архитектуры.
Самый эффективный способ — чётко разделять зоны ответственности и адаптировать их в процессе развития сервисов. Только так один административный руководитель сможет синхронизировать развитие разных сервисов.
Лет 5 назад у меня была команда, которая перешла целой группой в новое подразделение. Несмотря на использование общего шаблона для сервисов, общей инфраструктуры и инструментов, наши подходы и архитектурные решения со временем существенно разошлись.
Если бы эта команда была под моим управлением, то я бы не допустил такой "разбежки" в архитектурных решениях. Административным ресурсом можно повлиять, а уговорами и "джентльменскими соглашениями" — едва ли.
#разработка
Если не предпринимать дополнительных усилий, архитектура сервисов начнёт повторять организационную структуру. Это происходит естественным образом, так как в каждой структурной единице руководители имеют разные стратегии, принимают разные решения, что приводит к эволюции технических сервисов иногда даже в противоположные стороны.
Соответственно, чтобы архитектуры развивались гармонично, нужно либо выстраивать гармоничные зоны ответственности, либо вкладывать дополнительные ресурсы на поддержание общей архитектуры.
Самый эффективный способ — чётко разделять зоны ответственности и адаптировать их в процессе развития сервисов. Только так один административный руководитель сможет синхронизировать развитие разных сервисов.
Лет 5 назад у меня была команда, которая перешла целой группой в новое подразделение. Несмотря на использование общего шаблона для сервисов, общей инфраструктуры и инструментов, наши подходы и архитектурные решения со временем существенно разошлись.
Если бы эта команда была под моим управлением, то я бы не допустил такой "разбежки" в архитектурных решениях. Административным ресурсом можно повлиять, а уговорами и "джентльменскими соглашениями" — едва ли.
#разработка