Когда же наконец отстанут от Васи и дадут ему просто писать код </i>
А если серьезно, то разобраться в том, что именно, для кого и зачем разрабатывать - это тоже важная часть работы. И успех в этом деле напрямую влияет на то, будет ли код Васи приносить пользу людям.
TPM это тот же PM, просто с допнагрузкой, или их теперь двое «пээмить» будут?
Мне кажется, что тут нет однозначного ответа, который подошел бы ко всем ситуациям. Где-то один TPM делает все и норм. А где-то работает связка PM + TPM, где первый, например, больше занимается вопросами привлечения. А где-то вообще несколько TPM - я видел разные конфигурации:)
Но с другой стороны, эта роль как будто просто попадает в общий тренд "генерализации" профессий. Мало быть специалистом в одной специализации, для "успеха" надо шарить ещё и в смежных. 10-15 лет назад было нормой, что разработкой занимаются одни люди, а эксплуатацией системы другие - сейчас это скорее исключение. Такая же история и в менеджменте.
Статья во многом на опыте Т-Банка, но не ограничивается им - я общался с TPMами и других компаний про их работу, чтобы сложить общий взгляд. А сам я из Яндекса.
- Хотелось бы побольше узнать именно о способах мониторинга - дашборды, алерты, там много интересного - поиск проблем (умный анализ, сравнение со старыми данными, SLO), предсказания (праздники, какие-то события и т д), банально доставка уведомлений (способы, эскалация), ротация, ownership, и т д.
- Есть ли процесс инцидент-менеджмента, постмортемы, как продвигаете observability-культуру в компании?
Вопросы интересные, но чтобы ответить по существу, надо заряжать отдельную статью:)
- Насколько понял по описанию, тест старта приложения замеряет только запросы, что мешает добавить данные в уже существующий запрос?
Ничего не мешает. Добавление каких-то данных в существующий запрос/ответ в общем случае не так опасны как добавление новых запросов. Поэтому за этим системно не следим, по крайней мере со стороны платформы мобильного банка.
Ну и любопытно про проблему с конфигом:
- Почему вы не узнали о ней от бэкенд-разработчиков, наверное, они не только ошибки мониторят, но и количество запросов? Все сервисы, что за главным экраном должны были потерять трафик с Android (самого популярного клиента)
Тут, как это обычно бывает, случилось сочетание обстоятельств. Во-первых, о проблеме мы действительно узнали от SRE. Во-вторых, прямо перед нашим сбоем случился другой сбой на сервисе историй и SRE занимались его устранением. По ходу работы над ним ребята перепроверяли как в мобильном банке отображаются истории и застали самое начало уже нашего сбоя. Поэтому данные о падении трафика оказались невостребованными в тот момент.
- Как обрабатывалась ошибка парсинга, что ее тоже никто не заметил, try с пустым catch?)
На этапе парсинга конфига выбросили исключение, а выше уровнем криво его обработали. Клиенту в UI ничего не показали и получилось, что данные для Главного экрана просто не прогрузились и он остался пустым.
Технически это восстановление приложения с другого аккаунта, на котором нужное приложение есть. Такое умеет делать iMazing и такую логику можно воспроизвести с использованием open source утилит
Но факты говорят сами за себя - некоторым банкам, которые тоже удалили из App Store, удалось опубликоваться с разной степенью камуфляжа. Так что это не что-то невозможное.
Часть продолжает пилить фичи, чтобы клиенты получили их, когда мы релизнимся в App Store. Другая часть активно работает над тем, что бы этот самый релиз случился:)
С возвращением на Хабр вас!:)
В свое время ваши статьи на Хабре и в блоге, а также некоторые курсы помогли по-новому посмотреть на себя и на разные рабочие вопросы.
Круто! Спасибо за статью и отдельное спасибо, что не поленились так подробно всё заскринить!:)
Единственное, что во всем этом меня напрягает (если это кого-то вообще интересует), так это то, что вся логика обработки ответов находится у Google. И «по щучьему велению» внезапно может произойти так, что этот сервис окажется для Google «не перспективным» и закроется, и все останутся у разбитого корыта. Конечно, я понимаю, что сервис бесплатный и никто никому ничем не обязан, но внутренний параноик забеспокоился.
Когда же наконец отстанут от Васи и дадут ему просто писать код </i>
А если серьезно, то разобраться в том, что именно, для кого и зачем разрабатывать - это тоже важная часть работы. И успех в этом деле напрямую влияет на то, будет ли код Васи приносить пользу людям.
Мне кажется, что тут нет однозначного ответа, который подошел бы ко всем ситуациям. Где-то один TPM делает все и норм. А где-то работает связка PM + TPM, где первый, например, больше занимается вопросами привлечения. А где-то вообще несколько TPM - я видел разные конфигурации:)
Да, безусловно, есть в этом что-то.
Но с другой стороны, эта роль как будто просто попадает в общий тренд "генерализации" профессий. Мало быть специалистом в одной специализации, для "успеха" надо шарить ещё и в смежных. 10-15 лет назад было нормой, что разработкой занимаются одни люди, а эксплуатацией системы другие - сейчас это скорее исключение. Такая же история и в менеджменте.
Ничего, два добрых фидбека - в два раза приятней читать!)
Спасибо за отзыв!
Спасибо за добрый фидбек! Рад, что статья зашла:)
Статья во многом на опыте Т-Банка, но не ограничивается им - я общался с TPMами и других компаний про их работу, чтобы сложить общий взгляд. А сам я из Яндекса.
О, как раз надо скоро купить телек. Штош, спасибо за пост, буду держаться от телевизоров Sber подальше
Случилась реинкарнация древнего мема he Protec but he also attac
Ульяна, спасибо за полезную статью:)
Вопросы интересные, но чтобы ответить по существу, надо заряжать отдельную статью:)
Ничего не мешает. Добавление каких-то данных в существующий запрос/ответ в общем случае не так опасны как добавление новых запросов. Поэтому за этим системно не следим, по крайней мере со стороны платформы мобильного банка.
Тут, как это обычно бывает, случилось сочетание обстоятельств. Во-первых, о проблеме мы действительно узнали от SRE. Во-вторых, прямо перед нашим сбоем случился другой сбой на сервисе историй и SRE занимались его устранением. По ходу работы над ним ребята перепроверяли как в мобильном банке отображаются истории и застали самое начало уже нашего сбоя. Поэтому данные о падении трафика оказались невостребованными в тот момент.
На этапе парсинга конфига выбросили исключение, а выше уровнем криво его обработали. Клиенту в UI ничего не показали и получилось, что данные для Главного экрана просто не прогрузились и он остался пустым.
Технически это восстановление приложения с другого аккаунта, на котором нужное приложение есть. Такое умеет делать iMazing и такую логику можно воспроизвести с использованием open source утилит
Спасибо за добрую обратную связь!
Спасибо за обратную связь!
Да, с Vitals все так. А другим сторам ещё далеко до такой аналитики, которую давал Google.
В целом, согласен.
А какие альтернативы вы видите? При условии, что клиенты с iOS никуда не ушли и их все равно значимая часть.
Не без это, конечно.
Но факты говорят сами за себя - некоторым банкам, которые тоже удалили из App Store, удалось опубликоваться с разной степенью камуфляжа. Так что это не что-то невозможное.
Часть продолжает пилить фичи, чтобы клиенты получили их, когда мы релизнимся в App Store. Другая часть активно работает над тем, что бы этот самый релиз случился:)
В свое время ваши статьи на Хабре и в блоге, а также некоторые курсы помогли по-новому посмотреть на себя и на разные рабочие вопросы.
Единственное, что во всем этом меня напрягает (если это кого-то вообще интересует), так это то, что вся логика обработки ответов находится у Google. И «по щучьему велению» внезапно может произойти так, что этот сервис окажется для Google «не перспективным» и закроется, и все останутся у разбитого корыта. Конечно, я понимаю, что сервис бесплатный и никто никому ничем не обязан, но внутренний параноик забеспокоился.