Привет! Меня зовут Саша Тармолов и я работаю в Яндексе, а точнее в Яндекс Гео, уже > 10 лет 🙈
Периодически друзья, с которыми давненько не виделись, задают мне вопрос вида: “А ты еще до сих пор в Яндексе? Ты ещё там все не переделал? Не надоело?”
И вы знаете… нет, не надоело. И нет, не переделал 🙂
Если честно, то я что-то не могу припомнить два года, чтобы я занимался идентичной работой. Постоянно происходят какие-то изменения, необходимо подстраиваться и развиваться. Профиль моей работы знатно изменился за это время. То, чем я занимался в первый год работы в компании и сейчас — это небо и земля.
За время работы наша команда выработала эффективные подходы в работе и накопила много полезного опыта. В общем, есть чем поделиться.
Цель этого канала — немного приоткрыть дверцу и рассказать о нашей внутренней кухне. Я попробую поработать интерфейсом к тому, что у нас происходит внутри. Возможно, что кому-то наш опыт окажется полезен, а кому-то придется по душе наша философия и он/она захотят присоединиться к нашей команде 😉
Периодически друзья, с которыми давненько не виделись, задают мне вопрос вида: “А ты еще до сих пор в Яндексе? Ты ещё там все не переделал? Не надоело?”
И вы знаете… нет, не надоело. И нет, не переделал 🙂
Если честно, то я что-то не могу припомнить два года, чтобы я занимался идентичной работой. Постоянно происходят какие-то изменения, необходимо подстраиваться и развиваться. Профиль моей работы знатно изменился за это время. То, чем я занимался в первый год работы в компании и сейчас — это небо и земля.
За время работы наша команда выработала эффективные подходы в работе и накопила много полезного опыта. В общем, есть чем поделиться.
Цель этого канала — немного приоткрыть дверцу и рассказать о нашей внутренней кухне. Я попробую поработать интерфейсом к тому, что у нас происходит внутри. Возможно, что кому-то наш опыт окажется полезен, а кому-то придется по душе наша философия и он/она захотят присоединиться к нашей команде 😉
Как любая крупная и серьезная компания, все изменения (ну ладно, почти все!) в наших продуктах мы выкатываем через эксперименты. На то есть вполне понятное обоснование: мы делаем массовые продукты и любое изменение может сильно осложнить жизнь миллионам наших пользователей.
Чтобы удостовериться, что новая фича точно будет полезна, мы вначале делаем ее доступной только небольшому проценту наших пользователей, потом скурпулезно считаем метрики и делаем выводы.
Очень часто мы используем подход “раскатить на внутреннюю сеть”, т.е. дать доступ только сотрудникам компании. Это самая лояльная аудитория, но и очень требовательная. Критики можно огрести целый вагон, или два, или пять.
Этот канал — не исключение. Качу его на “внутреннюю сеть”, чтобы мои коллеги оценили и провалидировали то, что я пишу. А также, конечно, нужно понять хватит ли у меня терпения и времени, чтобы снабжать этот канал чем-то интересным 🙂
Тем не менее. Запускаю эксперимент.
Ссылка для того, чтобы зайти в чат: https://www.tgoop.com/+Y9WeNBsCzaYwYWRi
Дата старта эксперимента: 7 сентября 2022 года.
Дата окончания эксперимента: 7 декабря 2022 года.
Длительность: 3 месяца (эдакий испытательный срок)
Метрика: голосование коллег + получить “ок” от команды нашего pr + наличие новых тем
Чтобы удостовериться, что новая фича точно будет полезна, мы вначале делаем ее доступной только небольшому проценту наших пользователей, потом скурпулезно считаем метрики и делаем выводы.
Очень часто мы используем подход “раскатить на внутреннюю сеть”, т.е. дать доступ только сотрудникам компании. Это самая лояльная аудитория, но и очень требовательная. Критики можно огрести целый вагон, или два, или пять.
Этот канал — не исключение. Качу его на “внутреннюю сеть”, чтобы мои коллеги оценили и провалидировали то, что я пишу. А также, конечно, нужно понять хватит ли у меня терпения и времени, чтобы снабжать этот канал чем-то интересным 🙂
Тем не менее. Запускаю эксперимент.
Ссылка для того, чтобы зайти в чат: https://www.tgoop.com/+Y9WeNBsCzaYwYWRi
Дата старта эксперимента: 7 сентября 2022 года.
Дата окончания эксперимента: 7 декабря 2022 года.
Длительность: 3 месяца (эдакий испытательный срок)
Метрика: голосование коллег + получить “ок” от команды нашего pr + наличие новых тем
Тармолов про работу
BTW сегодня важный день. Именно в этот день были опубликованы первые карты Яндекса. Продолжаем делать крутой продукт для миллионов уже 18 лет!
Кстати, про первую версию Яндекс Карт.
Она состояла из фрагментов карты и если кто-то хотел посмотреть карту Москвы, то нужно было открыть одну вкладку, а если карту Санкт-Петербурга — то другую.
Также первую версию Яндекс Карт нельзя было драгать мышкой. Навигация осуществлялась стрелочками. Нажимаешь на стрелочку “вправо” и получаешь новый фрагмент карты. Захотел вернуться назад? Нажимаешь стрелочку “влево”. Любой клик приводил к полной перезагрузке страницы. Зато работало в любом браузере!
К слову, когда я присоединился к команде Яндекс Карт, то тачевая версия продолжала работать по той же логике. Под капотом использовался “тайловый принтер”, который по запросу отдавал фрагмент карты в виде картинке.
Позже мы выпустили “тайловый принтер” в виде публичного API и теперь каждый желающий может повторить функциональность первой версии карт :)
#гео
Она состояла из фрагментов карты и если кто-то хотел посмотреть карту Москвы, то нужно было открыть одну вкладку, а если карту Санкт-Петербурга — то другую.
Также первую версию Яндекс Карт нельзя было драгать мышкой. Навигация осуществлялась стрелочками. Нажимаешь на стрелочку “вправо” и получаешь новый фрагмент карты. Захотел вернуться назад? Нажимаешь стрелочку “влево”. Любой клик приводил к полной перезагрузке страницы. Зато работало в любом браузере!
К слову, когда я присоединился к команде Яндекс Карт, то тачевая версия продолжала работать по той же логике. Под капотом использовался “тайловый принтер”, который по запросу отдавал фрагмент карты в виде картинке.
Позже мы выпустили “тайловый принтер” в виде публичного API и теперь каждый желающий может повторить функциональность первой версии карт :)
#гео
Сложности коммуникации
В далеком 2013 году я оборудовал для нашей команды специальное место со смартфонами/планшетами разных производителей. Когда разработчику/тестировщику нужно было найти/пофиксить баг на каком-то конкретном смартфоне, то он/она шли к такому шкафу и с помощью специальной “пикалки” (считыватель штрих-кодов как в магазине) записывали девайс на себя, чтобы коллеги знали кто что взял.
В первой версии стенда со девайсами не рекомендовалось уносить устройства со стенда, т.к. их не было ограниченное количество. Соответственно, нужно было организовать небольшое рабочее место со столом и стулом, чтобы любой желающий мог так временно поработать.
У нас в компании есть специальные “девопсы” по инфраструктуре со службой единого окна, через которую можно заказать и монитор, и мебель и даже цветок на свой рабочий стол. За этим единым окном сокрыто много внутренних команд, которые следят за комфортом офиса.
Вот фрагмент переписки:
— Когда-то давно мы заказывали стол и стул для тестового стенда. Девайсы стали появляться, а стола/стула до сих пор нет. Наверное, наша заявка где-то потерялась. Можно перезаказать?
— Здравствуйте! стол-стул принесли.
Радуюсь, прихожу проверить, стола/стула не обнаруживаю. Однако, возле своего рабочего стола вижу небольшой столик. Спрашиваю у коллег что это и для кого? Пожимают плечами и говорят, что для меня принесли.
Закрадывается сомнение, что это не просто совпадение. Начинаем с коллегами рассуждать и тут мы понимаем, что моя заявка была выполнена, но с небольшим багом. При адресации заявки “стол и стул” случайно преобразовались в “стол-стул” и мне принесли стул-трансформер, который можно превратить в стол и обратно!
Вот так мы и поиграли в сломанный телефон:
Мораль: в общении в любой момент может случиться непонимание; старайтесь всегда последовательно и структурно доносить свою точку зрения, а то получите себе стол-стул 😉
P. S. Баг, конечно, исправили и принесли стол и стул без дефиса.
#байки
В далеком 2013 году я оборудовал для нашей команды специальное место со смартфонами/планшетами разных производителей. Когда разработчику/тестировщику нужно было найти/пофиксить баг на каком-то конкретном смартфоне, то он/она шли к такому шкафу и с помощью специальной “пикалки” (считыватель штрих-кодов как в магазине) записывали девайс на себя, чтобы коллеги знали кто что взял.
В первой версии стенда со девайсами не рекомендовалось уносить устройства со стенда, т.к. их не было ограниченное количество. Соответственно, нужно было организовать небольшое рабочее место со столом и стулом, чтобы любой желающий мог так временно поработать.
У нас в компании есть специальные “девопсы” по инфраструктуре со службой единого окна, через которую можно заказать и монитор, и мебель и даже цветок на свой рабочий стол. За этим единым окном сокрыто много внутренних команд, которые следят за комфортом офиса.
Вот фрагмент переписки:
— Когда-то давно мы заказывали стол и стул для тестового стенда. Девайсы стали появляться, а стола/стула до сих пор нет. Наверное, наша заявка где-то потерялась. Можно перезаказать?
— Здравствуйте! стол-стул принесли.
Радуюсь, прихожу проверить, стола/стула не обнаруживаю. Однако, возле своего рабочего стола вижу небольшой столик. Спрашиваю у коллег что это и для кого? Пожимают плечами и говорят, что для меня принесли.
Закрадывается сомнение, что это не просто совпадение. Начинаем с коллегами рассуждать и тут мы понимаем, что моя заявка была выполнена, но с небольшим багом. При адресации заявки “стол и стул” случайно преобразовались в “стол-стул” и мне принесли стул-трансформер, который можно превратить в стол и обратно!
Вот так мы и поиграли в сломанный телефон:
стол и стул → стол стул → стол-стулМораль: в общении в любой момент может случиться непонимание; старайтесь всегда последовательно и структурно доносить свою точку зрения, а то получите себе стол-стул 😉
P. S. Баг, конечно, исправили и принесли стол и стул без дефиса.
#байки
Хочу завести рубрику — пятничные #байки. Буду рассказывать истории из наших рабочих будней: поучительные или смешные, с моралью и без, из моей жизни и моих коллег.
Хватит ли историй на каждую пятницу — это вопрос, но думаю, что коллеги помогут если что 🙂
Хватит ли историй на каждую пятницу — это вопрос, но думаю, что коллеги помогут если что 🙂
Тармолов про работу
Откопал немного фоток. Вот так выглядела первая версия стенда с устройствами
А вот это уже современный технологичный способ доступа к тестовым устройствам.
Красиво. Безопасно. Удобно.
Красиво. Безопасно. Удобно.
Одна из руководителей в Яндексе часто повторяла: “Люди — это главное”. Классных технологий и крутых продуктов не может существовать без сильной команды. Я полностью поддерживаю эту точку зрения и считаю, что каждый руководитель должен инвестировать в развитие своей команды.
Сегодня хочу немного рассказать про свою команду. Буду рассказывать больше, но с чего-то надо начать.
Я руковожу командой примерно в 50 человек. Мы активно участвуем в стажировках, поэтому в нашей численности есть некоторые флуктуации. Команда включает в себя специалистов самого разного профиля и все вместе мы формируем “самодостаточный разработческий модуль”, который может справиться с широким классом задач.
И не мудрено, т.к. в команде:
1. Фронтендеры
2. Бекендеры
3. Фулстеки
4. Тестировщики
5. Девопсы
6. и дажесистемный админстратор SRE
Наша команда расположена в разных городах и странах, но все же бОльшая часть сосредоточена в Москве. У нас допускается гибридный или удаленный режим работы, но мы больше верим в оффлайн общение. Как показала практика, так у нас получается работать наиболее эффективно. Ну и так веселее, конечно 🙂
В нашей зоне ответственности 50-60 проектов на разных стадиях своей жизни: от запуска новых до закапывания старых. Это могут быть и внутренние проекты, и внешние. Могут быть маленькие админки на 2-3 человек или же сервисы с многомиллионной аудиторией. Это может быть API или же сервис для конечного пользователя.
Обычно, чтобы показать масштаб того, чем мы занимаемся, я говорю: моя команда приложила руку почти ко всем картам Яндекса, что вы видите в интернете. Разумеется, честное исследование я не проводил, но “истина где-то рядом”…
#команда
Сегодня хочу немного рассказать про свою команду. Буду рассказывать больше, но с чего-то надо начать.
Я руковожу командой примерно в 50 человек. Мы активно участвуем в стажировках, поэтому в нашей численности есть некоторые флуктуации. Команда включает в себя специалистов самого разного профиля и все вместе мы формируем “самодостаточный разработческий модуль”, который может справиться с широким классом задач.
И не мудрено, т.к. в команде:
1. Фронтендеры
2. Бекендеры
3. Фулстеки
4. Тестировщики
5. Девопсы
6. и даже
Наша команда расположена в разных городах и странах, но все же бОльшая часть сосредоточена в Москве. У нас допускается гибридный или удаленный режим работы, но мы больше верим в оффлайн общение. Как показала практика, так у нас получается работать наиболее эффективно. Ну и так веселее, конечно 🙂
В нашей зоне ответственности 50-60 проектов на разных стадиях своей жизни: от запуска новых до закапывания старых. Это могут быть и внутренние проекты, и внешние. Могут быть маленькие админки на 2-3 человек или же сервисы с многомиллионной аудиторией. Это может быть API или же сервис для конечного пользователя.
Обычно, чтобы показать масштаб того, чем мы занимаемся, я говорю: моя команда приложила руку почти ко всем картам Яндекса, что вы видите в интернете. Разумеется, честное исследование я не проводил, но “истина где-то рядом”…
#команда
Гибкий график работы
В Яндексе не принято следить за отработанным временем, поэтому у нас никто не работает “от звонка до звонка”. Главное — это чтобы сотрудник справлялся со своими обязанности и продолжал эффективно взаимодействовать с командой.
В моей команде работало два уникальных разработчика: жаворонок и сова. Как вы можете догадаться, отличались они своим графиком работы, точнее своим “внутренним часовым поясом”.
Оба работали в одном офисе и сидели буквально через один стол. Они трудились в разных группах, общих проектов у них не было, но виделись они каждый день. Это было доковидное время, мы все работали в офисе и гибридного режима работы не было.
Далее случилось два параллельных события:
1. Разработчик-сова превратился в закоренелую сову и стал приходить на работу около 16 часов, а уходить домой за полночь. Мы часто пересекались с разработчиком-совой в столовой, но только я шел туда на ужин, а он — на обед.
2. Жаворонок превратился в раннего жаворонка и стал приезжать на работу в часов 6 (до пробок). Соответствено, рабочий день у него заканчивался где-то около 15 часов.
Оба разработчика нашли для себя свое идеальное время, когда можно поработать без лишних отвлекающих факторов: один — рано с утра, а другой — поздно вечером.
В таком режиме они прожили несколько месяцев, а может даже год. Точно не помню. Но в какой-то день что-то пошло не так: то ли разработчик-жаворонок засиделся, то ли разработчик-сова пришел пораньше. И они в итоге… встретились!
Сказать, что они удивились — ничего не сказать. Ведь первый вопрос, который один из них задал другому был “А ты еще работаешь в Яндексе?”. Оказывается, они оба думали, что другой коллега уже давно не работает в компании, т.к. они не виделись ооочень долгое время. Я не присутствовал на этой “роковой встрече”, но думаю, что для обоих она стала приятной неожиданностью.
Наверное, именно эта история наглядно демонстрирует гибкий график в нашей команде. Куда уж гибче?)
#байки
В Яндексе не принято следить за отработанным временем, поэтому у нас никто не работает “от звонка до звонка”. Главное — это чтобы сотрудник справлялся со своими обязанности и продолжал эффективно взаимодействовать с командой.
В моей команде работало два уникальных разработчика: жаворонок и сова. Как вы можете догадаться, отличались они своим графиком работы, точнее своим “внутренним часовым поясом”.
Оба работали в одном офисе и сидели буквально через один стол. Они трудились в разных группах, общих проектов у них не было, но виделись они каждый день. Это было доковидное время, мы все работали в офисе и гибридного режима работы не было.
Далее случилось два параллельных события:
1. Разработчик-сова превратился в закоренелую сову и стал приходить на работу около 16 часов, а уходить домой за полночь. Мы часто пересекались с разработчиком-совой в столовой, но только я шел туда на ужин, а он — на обед.
2. Жаворонок превратился в раннего жаворонка и стал приезжать на работу в часов 6 (до пробок). Соответствено, рабочий день у него заканчивался где-то около 15 часов.
Оба разработчика нашли для себя свое идеальное время, когда можно поработать без лишних отвлекающих факторов: один — рано с утра, а другой — поздно вечером.
В таком режиме они прожили несколько месяцев, а может даже год. Точно не помню. Но в какой-то день что-то пошло не так: то ли разработчик-жаворонок засиделся, то ли разработчик-сова пришел пораньше. И они в итоге… встретились!
Сказать, что они удивились — ничего не сказать. Ведь первый вопрос, который один из них задал другому был “А ты еще работаешь в Яндексе?”. Оказывается, они оба думали, что другой коллега уже давно не работает в компании, т.к. они не виделись ооочень долгое время. Я не присутствовал на этой “роковой встрече”, но думаю, что для обоих она стала приятной неожиданностью.
Наверное, именно эта история наглядно демонстрирует гибкий график в нашей команде. Куда уж гибче?)
#байки
Сейчас у нас в команде в самом разгаре ревью. Это один из ключевых процессов в компании, о котором стоит рассказать поподробнее.
Каждые полгода у нас в компании проходит процесс подведения итогов работы под названием #ревью (performance review). Когда компания вырастает из маленького стартапа в корпорацию, то необходим какой-то способ синхронизировать движение разных команд.
Большинство (а может и все?) крупных компаний в мире используют в своей жизни ревью в качестве инструмента по контролю эффективности компании.
Ревью — это прежде всего синхронизация:
— между сотрудником и руководителем, чтобы подвести результаты и сверить ожидания
— между смежниками через запрос обратной связи о своей работе и своих сотрудников
— между отделами для синхронизации оценок работы сотрудников и подразделений
К ревью также привязана и финансовая компенсация, что делает этот процесс ещё более ответственным и важным. Размер компенсации для каждого сотрудника вычисляется по секретной формуле, которая учитывает множество параметров.
Ревью добавляет цикличность в жизнь компании. Цикличность — это прежде всего предсказуемость и более уверенное планирование будущего. В нашей жизни есть привычные циклы смена дня и ночи или же времен года. Мы же добавляем еще дополнительные свои циклы: релизные циклы для софта или же ревьюшные циклы для оценки результатов.
Ревью состоит из следующих этапов:
1. Подведение итогов
2. Сбор обратной связи
3. Выставление оценки
4. Калибровки
5. Озвучивание результатов
Я расскажу о кажом этапе подробнее в следующих постах.
Большинство (а может и все?) крупных компаний в мире используют в своей жизни ревью в качестве инструмента по контролю эффективности компании.
Ревью — это прежде всего синхронизация:
— между сотрудником и руководителем, чтобы подвести результаты и сверить ожидания
— между смежниками через запрос обратной связи о своей работе и своих сотрудников
— между отделами для синхронизации оценок работы сотрудников и подразделений
К ревью также привязана и финансовая компенсация, что делает этот процесс ещё более ответственным и важным. Размер компенсации для каждого сотрудника вычисляется по секретной формуле, которая учитывает множество параметров.
Ревью добавляет цикличность в жизнь компании. Цикличность — это прежде всего предсказуемость и более уверенное планирование будущего. В нашей жизни есть привычные циклы смена дня и ночи или же времен года. Мы же добавляем еще дополнительные свои циклы: релизные циклы для софта или же ревьюшные циклы для оценки результатов.
Ревью состоит из следующих этапов:
1. Подведение итогов
2. Сбор обратной связи
3. Выставление оценки
4. Калибровки
5. Озвучивание результатов
Я расскажу о кажом этапе подробнее в следующих постах.
Во! Нарисовал картинку для демонстрации цикличности #ревью и получилось ревьюшное колесо 😁
Про #ревью могу порекомендовать два доклада:
— Ревью как устроена система оценки сотрудников в Яндексе от Сергея Бережного
— Нужно ли быть нормальным? от Андрея Стыскина
В первом докладе рассказывается высокоуровневая схема работы ревью, а во втором можно узнать сравнение двух версий систем ревью (старую и текущую).
Если вдруг знаете еще какие-то внешние доклады по теме, то накидайте плиз ссылок в комменты.
— Ревью как устроена система оценки сотрудников в Яндексе от Сергея Бережного
— Нужно ли быть нормальным? от Андрея Стыскина
В первом докладе рассказывается высокоуровневая схема работы ревью, а во втором можно узнать сравнение двух версий систем ревью (старую и текущую).
Если вдруг знаете еще какие-то внешние доклады по теме, то накидайте плиз ссылок в комменты.
YouTube
020. Ревью как устроена система оценки сотрудников в Яндексе – Сергей Бережной
Расскажу, как Яндекс оценивает сотрудников.
Одна из задач нашей команды — это обеспечивать работоспособность сервисов в режиме 24/7. Но иногда что-то идет не по плану и сервис ломается так, что от этого страдают наши пользователи. Мы называем такие ситуации инцидентами или на более жаргонном языке — факапами.
Вообще #инциденты — это неотъемлемая часть нашей жизни. Если сервис живет и развивается, то рано или поздно случится “идеальный шторм” и сервис “упадет”. У нас есть даже какая-то странная “традиция”, что в конце отчетного периода ревью мы ловим парочку инцидентов. Мы с SRE шутим, что это нужно для того, чтобы было что написать при подведении итогов 🙂
Историй про факапы и факапчики (младший брат факапа) у нас накопилось достаточно. Это много интересных и, я надеюсь, поучительных историй.
Вообще #инциденты — это неотъемлемая часть нашей жизни. Если сервис живет и развивается, то рано или поздно случится “идеальный шторм” и сервис “упадет”. У нас есть даже какая-то странная “традиция”, что в конце отчетного периода ревью мы ловим парочку инцидентов. Мы с SRE шутим, что это нужно для того, чтобы было что написать при подведении итогов 🙂
Историй про факапы и факапчики (младший брат факапа) у нас накопилось достаточно. Это много интересных и, я надеюсь, поучительных историй.
Неправильный ключ
Сегодня хочу рассказать про самый первый факап в Яндексе, свидетелем которого я стал.
Чтобы лучше понять что произошло, нужно дать немного контекста. Наши веб-карты в геосервисах использует для отображение карты Javascript API, которую мы поставляем наружу. Это классический “догфудинг”. API подключается на веб-странице и предоставляет нужную функциональность для отображения карты. Чтобы мы могли идентифицировать клиента, при подключении API необходимо передавать “ключ” (специальную сгенерированную строку).
Этот инцидент произошел более 10 лет. В то время веб-карты работали на самой первой версии нашего API. Эта версия API при передаче неправильного ключа “громко” ругалась в виде
Выкатили релиз. Мой руководитель открывает карты, чтобы после релиза немного “потыкать” интерфейс и убедиться, что все работает ожидаемо. И вместо карты ему вылетает алерт “Неправильный ключ”. Решает перепроверить url в браузере. Убеждается, что это боевое окружение. Все пользователи видят тоже самое, что и он.
РЕЖИМ ПАНИКИ MODE ON
На факапах всегда веселее с друзьями и коллегами, поэтому мой руководитель сразу голосом “призвал” (с щепоткой нецензурных слов) других разработчиков на эту “вечеринку”. Плохо помню детали и может где-то совру, но общую картинку расскажу скорее всего верно.
→ Проверяют конфигурацию проекта. Все верно. Ключ правильный. А в браузере — неправильный.
→ Разработчик отправляет заявку на откатывание релиза. Автовыкладка не срабатывает. Нужен админ.
→ Руководитель посылается гонца за админом.
→ Один из разработчиков заходит на сервер, чтобы выяснить причину.
→ Гонец сообщает, что админ ушел ужинать.
→ Звонят админу. Админ бросает недоеденную котлетку и бежит к разработке.
→ Разработчик выясняет, что в продакшене используется неверная конфигурация.
→ У всех права readonly на боевой сервер. Б-безопасность.
→ Прибегает запыхавшийся админ.
→ Админ пробует откатить релиз. Начинается процесс откатывания релиза.
→ Релиз откатился. Проверяют сервис и все наконец-то видят работающий сервис. Ура!
РЕЖИМ ПАНИКИ MODE OFF
На самом деле починку провели очень быстро. Сработали очень слаженно. Никто из пользователей не успел пожаловаться в поддержку на нерабочий сервис. Но команда сервиса получила неплохую порцию стресса, а админ недоел котлетку. Ну может про котлетку я и придумал, чтобы добавить экспрессии моему рассказу 🙂
#байки #инциденты
Сегодня хочу рассказать про самый первый факап в Яндексе, свидетелем которого я стал.
Чтобы лучше понять что произошло, нужно дать немного контекста. Наши веб-карты в геосервисах использует для отображение карты Javascript API, которую мы поставляем наружу. Это классический “догфудинг”. API подключается на веб-странице и предоставляет нужную функциональность для отображения карты. Чтобы мы могли идентифицировать клиента, при подключении API необходимо передавать “ключ” (специальную сгенерированную строку).
Этот инцидент произошел более 10 лет. В то время веб-карты работали на самой первой версии нашего API. Эта версия API при передаче неправильного ключа “громко” ругалась в виде
alert("Неправильный ключ"). Как вы можете догадаться, в одном из релизов веб-карт стали передавать неправильный ключ.Выкатили релиз. Мой руководитель открывает карты, чтобы после релиза немного “потыкать” интерфейс и убедиться, что все работает ожидаемо. И вместо карты ему вылетает алерт “Неправильный ключ”. Решает перепроверить url в браузере. Убеждается, что это боевое окружение. Все пользователи видят тоже самое, что и он.
РЕЖИМ ПАНИКИ MODE ON
На факапах всегда веселее с друзьями и коллегами, поэтому мой руководитель сразу голосом “призвал” (с щепоткой нецензурных слов) других разработчиков на эту “вечеринку”. Плохо помню детали и может где-то совру, но общую картинку расскажу скорее всего верно.
→ Проверяют конфигурацию проекта. Все верно. Ключ правильный. А в браузере — неправильный.
→ Разработчик отправляет заявку на откатывание релиза. Автовыкладка не срабатывает. Нужен админ.
→ Руководитель посылается гонца за админом.
→ Один из разработчиков заходит на сервер, чтобы выяснить причину.
→ Гонец сообщает, что админ ушел ужинать.
→ Звонят админу. Админ бросает недоеденную котлетку и бежит к разработке.
→ Разработчик выясняет, что в продакшене используется неверная конфигурация.
→ У всех права readonly на боевой сервер. Б-безопасность.
→ Прибегает запыхавшийся админ.
→ Админ пробует откатить релиз. Начинается процесс откатывания релиза.
→ Релиз откатился. Проверяют сервис и все наконец-то видят работающий сервис. Ура!
РЕЖИМ ПАНИКИ MODE OFF
На самом деле починку провели очень быстро. Сработали очень слаженно. Никто из пользователей не успел пожаловаться в поддержку на нерабочий сервис. Но команда сервиса получила неплохую порцию стресса, а админ недоел котлетку. Ну может про котлетку я и придумал, чтобы добавить экспрессии моему рассказу 🙂
#байки #инциденты
Ревью — это ответственный период и, конечно, он сопряжен со стрессом. Даже в текущей сложной обстановке в мире процесс ревью в нашей компании не останавливается и идет своим чередом.
А почему бы не отменить ревью и поставить всем сотрудникам повышенную оценку? Потому что количество денег у компании ограничено и выплатить всем повышенную премию не получится. Ок, ну давайте всем среднюю оценку поставим? Facebook же уже сделал так во время пандемии.
На первый взгляд звучит очень здраво. Но если мы поставим всем сотрудникам “средний результат”, то пострадает мотивация тех, кто работал на повышенную оценку и вкладывался в свою работу объективно больше своих коллег. Звучит не очень справедливо.
Именно поэтому в сложные периоды #ревью лучше не отменять, а делать его максимально “лайтовым”. Чем мы и занимаемся. Все ради соблюдения хрупкого баланса справедливости…
А кто-нибудь знает как сотрудники Facebook отреагировали на оценку “exceeds expectations” на ревью 2020 года?
А почему бы не отменить ревью и поставить всем сотрудникам повышенную оценку? Потому что количество денег у компании ограничено и выплатить всем повышенную премию не получится. Ок, ну давайте всем среднюю оценку поставим? Facebook же уже сделал так во время пандемии.
На первый взгляд звучит очень здраво. Но если мы поставим всем сотрудникам “средний результат”, то пострадает мотивация тех, кто работал на повышенную оценку и вкладывался в свою работу объективно больше своих коллег. Звучит не очень справедливо.
Именно поэтому в сложные периоды #ревью лучше не отменять, а делать его максимально “лайтовым”. Чем мы и занимаемся. Все ради соблюдения хрупкого баланса справедливости…
А кто-нибудь знает как сотрудники Facebook отреагировали на оценку “exceeds expectations” на ревью 2020 года?
1. Подведение итогов
В рамках #ревью мы имеем оцениваемый полугодичный период. В начале оцениваемого периода мы ставим цели, а в конце — достигнуты ли поставленные цели. Иногда цели могут видоизменяться в течение оцениваемого периода, это тоже учитывается.
У нас в компании каждый сотрудник пишет самоотзыв со своими ключевыми результатами.
Почему важно писать самоотзыв?
1. Руководители — не супергерои и они могут не вспомнить все ваши достижения до мельчайших деталей или забыть что-то важное. Никто лучше вас не знает то, что вы сделали и какие вершины покорили (и чего это стоило).
2. Описание ваших результатов помогает руководителю понять ваш взгляд на результаты работы, т.е. что вы считаете важнее, что наиболее челенжевым и т.д.
3. Важно понимать, что список результатов презентуется на калибровочных встречах в рамках ревью. Если вы поможете руководителю, то ему будет проще отстаивать ваши достижения.
4. Умение подвести итоги и дать им оценку — это важный скилл, который пригодится не только на работе, но и в личной жизни.
5. Достижения руководителя складываются из достижений членов его команды, поэтому если вы напишете список достижений, то сильно сэкономите время своему руководителю 🙂
Также я настоятельно рекомендую помимо ключевых результатов включать в самоотзыв и желаемую оценку. Нужно учиться реалистично оценивать свои результаты и калибровать свою “чуйку” с мнением руководителя.
В рамках #ревью мы имеем оцениваемый полугодичный период. В начале оцениваемого периода мы ставим цели, а в конце — достигнуты ли поставленные цели. Иногда цели могут видоизменяться в течение оцениваемого периода, это тоже учитывается.
У нас в компании каждый сотрудник пишет самоотзыв со своими ключевыми результатами.
Почему важно писать самоотзыв?
1. Руководители — не супергерои и они могут не вспомнить все ваши достижения до мельчайших деталей или забыть что-то важное. Никто лучше вас не знает то, что вы сделали и какие вершины покорили (и чего это стоило).
2. Описание ваших результатов помогает руководителю понять ваш взгляд на результаты работы, т.е. что вы считаете важнее, что наиболее челенжевым и т.д.
3. Важно понимать, что список результатов презентуется на калибровочных встречах в рамках ревью. Если вы поможете руководителю, то ему будет проще отстаивать ваши достижения.
4. Умение подвести итоги и дать им оценку — это важный скилл, который пригодится не только на работе, но и в личной жизни.
5. Достижения руководителя складываются из достижений членов его команды, поэтому если вы напишете список достижений, то сильно сэкономите время своему руководителю 🙂
Также я настоятельно рекомендую помимо ключевых результатов включать в самоотзыв и желаемую оценку. Нужно учиться реалистично оценивать свои результаты и калибровать свою “чуйку” с мнением руководителя.