Часть 2. В Яндексе
 
Я пришел в офис на Станиславского, где Яндекс занимал только пол-этажа. Вторую часть занимала компания Red Bull. Ещё помню, что в бизнес-центре работали строгие охранники и не давали мне кататься на “хилисах”.
 
Моя первая задача — разобраться с еще невыпущенной JS API, чтобы после запуска помочь первым пользователям. Я писал примеры, отвечал в клубе разработчиков, писал анонсы и посты. Одним словом, работал техническим саппортом.
 
В параллель я осваивал еще одну профессию — разработчик технической документации. Дело в том, что для JS API отсутствовало руководство для разработчиков. Я взялся его написать. Изучил инструменты документаторов, научился внятно формулировать свои мысли и интегрировал свое руководство в портал документации Яндекса.
 
Потом мне доверили разрабатывать внутренние инструменты. На самом деле это так круто, когда ты можешь поговорить со своими пользователями. На таких проектах просто молниеносный фидбек!
 
Следующий этап — внешние небольшие инструменты. Я написал первую версию конструктора карт. Тогда он назывался “API для секретарей”.  В первое реинкарнации конструктор позволял поставить одну точку и нарисовать одну линию. Сегодня конструктор карт — карточный Paint.
 
Через пару лет понадобилась помощь в развитии веб-карт и мне предложили перейти в соседнюю группу. Там я применил свои знания в документировании. У проекта появилась первая документация и шаблон описания типового проекта в нашей команде. Взамен получил здоровое чувство перфекционизма в написании кода 🙂
 
Я брался за те задачи, до которых не доходили руки. Что-то чинил, что-то ломал, а потом опять чинил. За свою любознательность и желанием "делать хорошо" вокруг себя я поплатился. Меня сделали руководителем группы из 3х человек.
 
А потом глазом не успел моргнуть, как я вырос до руководителя отдела, кем являюсь до сих пор. Каждый год характер моей работы и роль меняется, поэтому у меня складывается ощущение, что я постоянно меняю работу…
 
Тут я бы хотел рассказать, про много вещей:
— как я внедрял jslint и ругался на Дугласа Крокфорда
— как я полюбил vim и не расстаюсь с ним до сих пор
— про повышения до эпохи внедрения ревью
— как работало codereview и было ли оно вообще
— про психологически сложный переход в руководители отдела
 
…но давайте лучше про это поговорим как-нибудь в другой раз.
 
#команда

Как креативно подойти к наблюдению солнечного затмения? А вот так!

Двойник

У нас в команде используется несколько мессенджеров. Мы слишком демократичны в этом вопросе. Будь моя воля, то я бы диктатурой внедрил один мессенджер для однозначной связи с коллегами 😈
 
Самый используемый мессенджер — Telegram.
 
Однажды разработчику потребовалось забрать мобильное устройство со специального стенда. Я уже рассказывал про первую версию мобильного стенда. Потом появилась вторая более безопасная версия — в виде шкафа, который запирался на ключ.
 
Так вот. Коллега посмотрел логин ответственного за стенд и написал ему в Telegram с вопросом можно ли взять устройство. Тот разрешил. Мой коллега забрал девайс, починил баг и вернул его обратно. Вроде бы вопрос можно было бы посчитать закрытым, если бы не одно “но”.
 
Спустя какое-то время выяснилось, что коллега опечатался в написании логина и написал не тому человеку. “На другом конце провода” оказался ответственный за мобильные устройства, но не из нашей компании, а из Сбербанка. При чем уже тогда работал не в Сбербанке, а в Открытии.
 
При чем ответственный за устройства в Сбербанке подумал, что к нему по старой памяти пришел коллега из Сбербанка. Такие дела.
 
Единый мессенджер — это хорошо. Еще крайне желательно, чтобы он явным образом не давал возможности написать случайному человеку 🙂

#байки

Вот вам еще фото из архивов. Вторая версия мобильного стенда.

Лучше же первой? :)

Мои коллеги и друзья знают, что я люблю порядок. Поэтому в своей работе всегда выстраиваю логичную систему.

Этот телеграм-канал — не исключение. В нем тоже есть структурность в виде набора рубрик:
#яндекс — об общих процессах в компании
#гео — об Геосервисах
#команда — о нашей команде
#разработка — наши подходы в разработке
#инфраструктура — особенности построения инфраструктуры
#инциденты — наши факапы
#ревью — о полугодовом ревью
#байки — пятничная рубрика с историями из рабочих будней

Список рубрик будет в дальнейшем расширяться, а текущие — наполняться новыми постами 🙂

Можно вести свой контент-план в виде таблички или списка, но я решил выбрать более наглядный вариант — в виде своего рода диаграммы.

Золотой костыль

Разработчики Яндекса строили веб-сервисы на базе самописного движка xscript. Эта платформа собирала данные в xml формате, накладывала поверх xslt и получилась готовая html страничка или json в случае HTTP API.

Однажды один из таких HTTP API начал падать. Я закрыл проблемный сервер от входящего трафика, перезапустил xscript, проблема исчезла и я вернул нагрузку.

“Сетевые барабашки…”, — решил я. Проблема повторилась спустя полдня. Через сутки “заболел” второй сервер. Это уже не случайность, а проблема.

Пошел расследовать. HTTP сервис не менялся год, так же как и сам xscript. Зависимости также не менялись. Я дернул курлом сервис на проблемном сервере — ошибка воспроизводится. Далее решил локализовать проблему и удалил часть кода. Я перезапустил xscript — заработало. Вернул удаленный код обратно и ошибка не воспроизвелась.

Перезапуск помогает, но причину выяснить не удалось.

Мы дебажили эту проблему вместе с SRE, а затем и с бывшим мейнтейнером xscript. Не помогло. Нам удалось только выяснить, что проблема исчезает даже после обновления времени изменения файла.

Профессиональные разработчики нашли "элегантное" решение и для этой проблемы.

На серверах с этим сервисом запустили cron. Каждый час делался touch у одного единственного файлика 🙈 Иногда самым доступным и рабочим решением оказывается костылик.

P.S. Переход на nodejs повысили в приоритете.

#байки

Когда я только начал вести этот телеграмм-канал, то у меня было опасение, что тем хватит только на пару месяцев. Прошло два месяца, а количество тем не только не уменьшилось, а наоборот — увеличилось.

Контентного “топлива” хватит еще на многие месяцы вперед ;)

Два месяца назад я завел этот канал в качестве эксперимента. За это время я опубликовал 45 постов, включая 7 схем и 9 баек.

Возникла мысль подвести итоги этого эксперимента на месяц раньше. Напомню, чтобы открыть канал наружу, необходимо "озеленить" три метрики.

Метрики:
✔️ Получить одобрение от команды (ok получен)
✔️ Наличие новых тем (в запасе еще 100 топиков)
❓ Голосование коллег

Нужно мнение читалей, чтобы завершить эксперимент 🙂

Ура! Голосование поставило завершающую точку в эксперименте.
Теперь этот канал будет работать в публичном пространстве.

https://www.tgoop.com/tarmolov_work

Можно делиться с друзьями и коллегами 🙂

// TODO: переписать нормально
или
// TODO: оптимизировать этот код

Если грепнуть средний или крупный проект, то с вероятностью 100% будут найдены "тудушки" в коде. 

Они полезны при написании кода, чтобы не держать слишком большой контекст в голове. Но вот комитить "тудушки" — неудачная затея. Про них забывают. А даже если находят, то не помнят, что в них имелось ввиду.

Закомитьте "тудушку" в багтрекер с подробным описанием. Так "тудушка" превращается в полноценную задачку с рядом полезных бонусов:
- нет ограничения на описание
- доступны комментарии
- попадает на планирование по разбору техдолга

Багтрекерные "тудушки" — не гарантия, что их сделают. Но шансы будут выше.

#разработка

В прошлые выходные стал свидетелем, как двое ребят пытались завести автомобиль "с толкача": один толкал, другой пытался завести. Видно было, что "толкатель" выбился из сил.

Я вызвался помочь, и стали толкать вдвоем. Авто не заводилось. Мимо проезжало Яндекс Такси и остановилось. Водитель предложил поделиться бензином или "прикурить" аккумулятор. Дело было в другом, и мы вежливо отказались от просьбы.

Мимо пробегал курьер из Яндекс Лавки и также предложил помощь. Втроем удалось придать нужное ускорение и вывести на орбиту завести автомобиль.

В этот день руководитель из Яндекса, таксист Яндекс Такси и курьер Яндекс Лавки организовали филиал сервиса "Яндекс Помощь — поможем всем!"

Я не ограничиваю зону ответственности своей квартирой. Мне интересна судьба моего дома, двора и города. Поэтому помогаю ребятам толкнуть авто, чиню домики для птиц, сообщаю о сломанном дорожном знаке и ремонтирую свой подъезд. Это делает мир вокруг лучше.

Этот же подход масштабируется и на работу. Если смотреть на задачи шире и не ограничиваться только своим проектом, то в итоге от этого выиграют все. Таким образом расширяется круг влияния, появляются новые знакомства, и работа становится интереснее. А также появляются новые истории, которые можно рассказать :)

#байки

Я уже опубликовал две байки о наших инцидентах. И таких историй будет еще много. Инциденты — часть нашей повседневной работы.

Складывается впечатление, что сервисы моей команды работают с ошибками из-за некачественного кода, поверхностного тестирования или ненадежной инфраструктуры. Но это не так.

"Если бы строители строили здания так же, как программисты пишут программы, первый залетевший дятел разрушил бы цивилизацию" (с)

Я придерживаюсь следующих взглядов:
- Любое приложение содержит ошибки.
- Чем объемнее приложение, тем больше в нем ошибок.
- Частые релизы приложения приводят к новым ошибкам.
- Вероятность инцидентов повышается с ростом нагрузки.

Внештатные ситуации постоянно возникают. Если разработчик утверждает, что в его сервисе нет факапов, то или это выдуманный сервис, или в этом сервисе нет пользователей :)

Признание инцидентов — уже многое. Если это сделано, то можно сконцентрироваться на уменьшении ущерба. Это значит уметь делать раннюю диагностику и уменьшать время починки инцидента.

Мы много в это вкладываемся. Поэтому большинство наших инцидентов не видны пользователям.

#инциденты

2010 год. Столовая Яндекса. Час пик. Все столы заняты.

Мы с коллегой набрали еды и стали сканировать помещение в поисках свободного стола. Тут мы слышим чeй-то голос: "Ребят, садитесь за мой стол, я уже ухожу".

Голос принадлежал техническому директору Илье Сегаловичу. Сооснователь компании обедает в общей столовой и уступает место разработчикам. Раньше я с таким не сталкивался.

До Яндекса я учился в университете и работал в компаниях, где иерархия явно подчеркивалась. В Яндексе же границы иерархии размыты и все общаются на "ты".

Я начинал свою работу в технологическом стартапе "Яндекс", теперь работаю в корпорации "Яндекс". Несмотря на такой колоссальный рост компании, я продолжаю видеть проявление человечности Яндекса к своим сотрудникам.

Яндекс пересмотрел финансовую компенсацию сотрудников, сделав ее более прогнозируемой. До этого была выплачена дополнительная зарплата для поддержки сотрудников в неспокойные времена. Несмотря на затраты в миллионы рублей, компания это сделала.

А еще я стал свидетелем случаев поддержки отдельных сотрудников в трудных жизненных ситуациях. В них была оказана психологическая, финансовая и юридическая помощь.

"Люди — это главное" (с) Поэтому Яндекс так и поступает.

#байки #яндекс

Избежать инцидентов нельзя, поэтому важно научиться извлекать из них уроки. Этому помогает специальный процесс под названием Postmortem. В Яндексе этот процесс называется Live Site Review (LSR).

LSR — регулярная встреча для разработчиков, SRE и руководителей. На встрече выясняют причину инцидента и придумывают, как избежать рецидива в будущем. Часто выстраивают иерархическую структуру зависимостей, чтобы точнее подсчитать потери и найти компонент-источник “идеального шторма”.

Цель этих встреч — уменьшить количество инцидентов и сократить время на устранение таких проблем. Ни у кого нет цели устроить публичную расправу над "героями" LSR!

Результат каждого LSR — набор действий по исправлению багов, улучшению процесса, документации и т.п. Такие шаги называются action items (AI). Разработчики сервиса должны исправить недочеты, перечисленные в AI. За этим необходим строгий надзор.

LSR работают. Проверено Яндексом и нашей командой в частности. Я рекомендую внедрять практику LSR даже командам из 5 человек. Это правда повышает надежность сервисов.

#инциденты

Неожиданная связь

Я рассказывал об инциденте с неправильным ключом или о Кассандре. Сегодня пойдет речь о более серьезном инциденте — LSR с нашим внешним сервисом.

Начало "традиционное": сработали мониторинги → увеличились тайминги → сервис перестал обрабатывать нагрузку.

Проблема видна как внутренним, так и внешним пользователям. SRE кричит на опенспейс "ФАКАП!". 

Девопсы включились в работу:
- трафик не изменился
- подозрительные запросы отсутствуют
- в логах нет ничего подозрительного

Вдруг проблема исчезает так же неожиданно, как и появилась. Сидим в непонимании и пытаемся локализовать проблему.

Заходит коллега из соседней команды:
— Слушайте, я тут отключаю минорный бекенд. Там трафика — “слёзы”. Отключил, но сразу откатил, т.к. увидел у вас проблему. Это я вас задел?
— Нет. Это точно не связано. Можно вырубать.
— Ага. Тогда я через минут 10 опять его вырублю.

Коллега ушел, а мы продолжили расследование инцидента. Проходят 10 мин.

Срабатывают мониторинги → увеличиваются тайминги → сервис через пару минут перестанет обрабатывать нагрузку.

Таких совпадений не бывает! Пишем коллеге, чтобы вернул свой бекенд в строй. Проблема исчезает.

Оказалось, что наш сервис использовал отключаемый бекенд глубоко в “кишках” сервиса. Этот фрагмент кода написан много лет назад и жил по принципу “работает — не трогай”. Вызов бекенда был без таймаута, т.е. если бекенд не отвечал, то сервис ждал неразумное время. Также не было никакого логирования, что сильно усложнило диагностику.

В рамках LSR исправили проблему и настроили правильную деградацию сервиса.

Мораль: Bus factor — безумно важен! Если вам достался сервис в наследство, то разберите его на кирпичики. Это поможет вовремя наложить заплатку и не допустить инцидента в будущем.

#байки #инциденты

Каждая уважающая себя компания вкладывается в безопасность персональных данных клиентов. Тем не менее эти данные могут "утечь" в публичный доступ. И это происходит постоянно.

Я придерживаюсь нескольких принципов касательно безопасности:
- генерируемые пароли из менеджера паролей
- авторизация: двухфакторная и биометрия, где возможно
- использование yubikey как второго фактора
- определитель номера
- пароль на sim-карту и запрет на перевыпуск sim-карты по доверенности
- данные в облаке без "порочащих репутацию материалов"
- нескольких банков и брокеров для финансов
- официальное ПО и ОС без jailbreak
- не открывать ссылки от незнакомых людей и организаций

Принципы выше затрудняют взлом аккаунтов и уменьшают ущерб. Лучше предпринять шаги заранее, чем потом рвать на себе волосы.

И, конечно, будьте всегда бдительны!

#безопасность