​​Network performance: latency в TCP

На базе протокола TCP работает множество протоколов более высокого уровня: HTTP, HTTPS, Websocket, SMTP, POP3, IMAP, всякие самодельные и велосипедные протоколы. Большая часть современного веба построена на базе протокола TCP. В TCP в отличии от UDP требует установки соединения. Прежде чем поговорить о плюсах и минусах стоит углубиться в процедуру установки соединения, дьявол в деталях...

И так, у нас есть клиент что желает получить информацию с сервера, например, браузер хочет загрузить страницу вебсайта по HTTP. Клиент подключается по протоколу TCP к серверу. Установка соединения начинается с отправки клиентом пакета с флагом SYN (специальный флаг для индикации что это новое соединение). Затем сервер отправляет пакет с флагом SYN+ACK клиенту обратно. Вместе с этими двумя пакетами передаются еще флаги для настройки взаимодействия, чексума, номера портов. etc. После получения SYN+ACK клиент отправляет пакет с флагом ACK, который является последним звеном в handshake между клиентом и сервером. Вместе с третим пакетом можно отправлять данные. Пакеты ограничены по размеру и весь запрос и ответ может не уместиться в один пакет и тогда придется отправить больше пакетов.

В итоге, пока клиент ждет SYN+ACK никакого обмена информацией не происходит. Помните про Hibernia Express с их супербыстрым оптоволокном? Вот в той сети между Нью-Йорком и Лондоном round trip time (RTT) составляет 55ms, в один конец это 27.5ms, половина RTT. Даже с таким низким latency до момента получения ответа от сервера, если он отвечает моментально, потребуется 110ms. Для клиента из Далласа (США) до сервера в датацентре в Амстердаме требуется минимум 450-460ms на получение первого байта ответа.

Когда соединение уже установлено и используется повторно, то можно сэкономить и вместо 450-460ms обменяться данными за 1 RTT,  т.е. 226ms.

Но это все идеальные сценарии. В реалиях все еще хуже...

​​🐢 Network performance: latency c TCP+TLS (HTTPS)

Для установки TCP соединения потребуется 3-way handshake. Одно лишь время на установку соединения и получения первого байта ответа может превысить 500-600мс для самых отдаленных уголков планеты. Тот же протокол HTTP, который является базовым для всего современного веба, работает поверх протокола TCP, потому загрузка контента по HTTP зависит от расстояния между клиентом и сервером и от потерь на канале.

Для защищенного протокола HTTPS latency еще больше. HTTPS является расширением протокола HTTP и тоже работает поверх TCP. Если же по протоколу HTTP данные ходят в незашифрованном виде и могут быть перехвачены, то в HTTPS данные отправляются в зашифрованном виде и перехват трафика не позволит увидеть передаваемые данные, например, пароли. Это достигается путем использования протокола TLS.

Современные браузеры топят за безопасность пользователей и не очень любят сайты использующие не защищенные протоколы: сайты маркируются как небезопасные и пользователи меньше им доверяют. Поисковые движки вообще используют этот критерий для ранжирования сайтов. Потому наличие https важно.

Только вот не дается это бесплатно и за безопасность платим latency. При скачивании файлов по HTTPS тоже потребуется установить TCP handshake, а затем установить и безопасное соединение произведя TLS handshake который требует аж 8 операций обмена данными. Возьмем реальные данные из прошлой публикации и подсчитаем минимальное количество времени что уйдет от момента запроса до момента получения данных… 900-910мс!

Для клиента из Далласа (США) запрашивающего контент из датацентра в Амстердаме на получение первого байта ответа потребуется:
🔸минимум 450-460ms для загрузки по HTTP;
🔸минимум 900-910ms для загрузки по HTTPS.

Как видно, это очень дорогая операция. Напомню, что по статистике половина пользователей ожидает загрузки сайта менее чем за 2 секунды, а мы минимум 0.9 секунды тратим на установку соединения. Представьте что еще стоит редирект и делается повторное соединение и еще +0.9 секунды… Но пути оптимизации существуют и я расскажу как уменьшить latency и сделать пользователей счастливее. Stay tuned!

🗣 Network performance: замеры ping’ов

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

Я использовал https://wondernetwork.com/pings. Этот сервис в real time из разных локаций пингует пул серверов, анализирует данные и позволяет получить примерное представление о задержках. Он считает минимальные и максимальные значения, а также среднеквадратические отклонения.

У реальных пользователей история будет другая ибо есть фактор последней мили. Но это уже другая история. Пишите боту свои вопросы!

​​🚀 Network performance: уменьшение latency через CDN

До того как перейдем к техническим деталям оптимизаций TCP скину самый дешевый вариант ускорения отдачи. Речь пойдет о Content Delivery Network (CDN).

Можно хранить, обрабатывать и отдавать всю информацию напрямую с хостинга (датацентра, облака и т.п.) где размещается сайт. Независимо от того 1 гигабайт в день отдается или 1000 гигабайт, проблема со скоростью загрузки страниц, скорость ответа ajax запросов и скорости загрузки изображений/статики остается. Если страницы грузятся долго, то пользователь уходит.

Дабы ускорить время отдачи используют кэширование и CDN. CDN - это сеть по раздаче контента, которая состоит из множества точек присутствия (PoP, Point of Presence), а в точках присутствия множество Edge серверов, для целей масштабирования. CDN настраивается с указанием сервера откуда брать данные (например, хостинг с сайтом) и этот сервер называется Origin сервером.

Ранее я обьяснял почему для протокола TCP (HTTP и HTTPS особенно) критично расстояние от пользователя до сервера к которому происходит подключение. CDN решает проблему latency благодаря близости к пользователю запрашивающего контент этих самых PoP. Чем ближе тем быстрее. "Воу, а если edge находится далеко от origin, то ему все равно надо делать handshake и это те же временные затраты", - скажет внимательный читатель. Эта проблема решается путем установки соединений и поддержании соединений между Edge и Origin, потому когда пользователь запрашивает с Edge данные требующего обращения на Origin, то запрос пойдет по уже установленному соединению и время ответа в лучшем случае будет равно 1 RTT.

Вторая важная функция - это кэширование. Если пользователи запрашивают один и тот же файл регулярно, то его можно скачать один раз, хранить в PoP где Edge может быстро найти данные и отдать клиенту без обращения к Origin. Это значительно экономит время ответа.

Я неоднократно сталкиваюсь с историями когда на некотором ресурсе страница или изображение зависрусилось и хостинг падает либо из-за перезрузки, либо же из-за ограничений пропускного канала тормозит. С кэширующим CDN таких проблем тоже можно избежать, ведь данные отдаются с PoP имеющих большой запас по пропускной способности.

CDN решений валом у клауд провайдеров, у того же Google Cloud, Amazon и т.п. Если ваш проект находится в клауде, то убедитесь что вы настроили отдачу через CDN этого клауда. Если отдача данных с Amazon S3, то проверьте не ходит ли напрямую пользователь на S3. Подключение CDN точное не будет дороже (для облака!), зато даст прирост производительности.

Итого, что имеем? В приведенном ранее примере с юзером в Далласе и сервером в Амстердаме можно ускорить время ответа с 450-460ms до 240-250ms. С кэшированием вплоть до 20-30ms.

🧭 Network performance: уменьшение latency с DNS

Сразу спойлер. Выводы и рекомендации в самом конце! Поехали.

Независимо подключен ли CDN для раздачаи статики и основного контента браузеру пользователя потребуется узнать куда обращаться за данными. Дабы подключится к серверу необходимо знать его IP адрес. Пользователь мог бы явно обращаться и писать https://183.92.46.12/, но это неудобно. Второй минус прямого обращения в том, что это рушит принцип работы классических CDN. Потому был придуман протокол DNS (кстати, работает как по UDP, так и по TCP). Его задача состоит в преобразовании хостнеймов в IP адреса.

Разберем на примере как происходит определение IP адреса. Браузер получает запрос на открытие страницы и запрос содержит hostname, допустим mycfdistribution.cloudfront.net. Скорее всего у браузеров реализован свой кэш уровень и он сперва проверит налиие адресов в кэше. В случае наличия ответа в кэше сразу произойдет обащение на заданный IP адрес. Если в кэше записи нет, то начинается процедура определения и это уже задача операционной системы. Я ранее писал подробную публикацию о том как Linux системы определяют механизм получения адреса: это довольно подробный анализ и останавливаться не буду на этом... перейдем сразу к шагу общения с DNS-серверами.

Если ОС пользователя получила настройки сети от провайдера, то с большой вероятностью провайдер предоставил свой локальный DNS-сервер. ОС пользователя шлет запрос на этот DNS и у него тоже есть функционал кэширования. Кэширование эффективно работает при обращении а популярне домены, google.com и т.п. Для менее популярных сайтов записи в кэше вероятно не будет и DNS-сервер вынужден обращаться к другим серверам для получения информации. Но куда обращаться-то? Сперва обращение пойдет на root сервер который отвечает за всю зону .net (a.gtld-servers.net) с целью получить информацию о cloudfront.net. Получив ответ DNS-сервер знает authoritative DNS-сервер которых зранит информацию о конкретном сабдомене, т.е. mycfdistribution.cloudfront.net и обращается к нему для получения IP-адреса для получения контента.

В этой цепочке наверняка в кэше локального DNS резолвера будет информация о net зоне, а поскольку cloudfront довольно популярен, то вероятность что он тоже будет в кэше высока, потому запрос будет только к authoritative самого cloudfront.

Много текста. Какой вывод?
🍒 Чем меньше сабдоменов тем лучше, если делать CDN для статики только, то лучше на отдельный домен его повесить чем на сабдомен.
🍉 Свои NS сервера или сервера третьесортного хостера хуже чем Route53, Cloudflare, OpenDNS и т.п.
🥝 Клепать для дистрибьюции отдельно сабдомены для изображений, css, js - глупость, разные самбдомены для шардирования тоже.
🍓 Свои системы лучше настривать чтобы NS сервера были гугловыми или Cloudflare. Меньше лишних звеньев в цепи.
🍏 Учитывая что у многих пользователей вбиты NS от Google или Cloudflare, то выгоднее с точки зрения минимизации latency лучше использовать их. Для этих пользователей будет резолвится супер быстро.

Сделать взвешенный выбор поможет https://www.dnsperf.com/, но энивей в синтетике победитель Cloudflare, с чем его и поздравляем. О том как подходят большие пацаны в борьбе с latency в резолве будет в следующих постах.

​​🍿Анонс истории: релиз после года разработки и debug под новогодний звон бокалов

Более трёх лет назад мне довелось взять на себя ответственность по проектированию и построениею системы в доменной зоне в которой ни у меня, ни у команды не было экспертизы. Домен еще и сложен сам по себе в виду работы с real time video streaming и его доставкой для B2B клиентов, а там worldwide, low latency, масштабируемость и все такое.

Первым делом занялся трансляцией требований бизнеса в архитектуру что была бы приемлема по стоимости с одной стороны, а с другой стороны могла бы масштабироваться и могла бы быть реализована в срок. Если опыта за 10+ лет инженерии для построение архитектуры хватило, то экспертизы в технологическом стеке не было. Логично было начать искать подрядчиков для реализации этой системы. Они были найдены, UML диаграммы и описание API всех слоев были переданы на реализацию, через 4-6 месяцев получили систему и зарелизили первую версию. Год потребовался чтобы осознать две вещи:
🔸вылезли косяки имплементации что нарушали требования архитектур, а на приемке не могли быть найденными, слишком специфичные кейсы;
🔸с ростом инфраструктуры и пользователей косяки начали существенно мешать и негативно влиять на user experience;
🔸контракторы крайне вяло шли на контакт и устранялись от проблем.

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

Год заняло переписывание слоев видеостриминг платформы. Был только один core компонент что оставался 3rd party для нас - это Wowza Streaming Engine написанный на Java, с закрытым кодом и индусским саппортом. Но load tests показывали хорошие показатели и этот black box оставили в проекте. Был полностью переписан код логики управления слоями, внесена логика что не было реализована изначально, но было зафиксировано в архитектуре. Все тщательно тестировалось, даже нагрузочные были…

Дедлайн был до конца 2017 года, эту дату прежде всего я и команда зафиксировали сами и подписалась под ним. Потому мы решили зарелизиться в последние недели декабря. Спустя несколько дней после релиза стало понятно что у Хьюстона проблемы: сервис транскодирования видео начал чаще чем прежде сигнализировать об обрывах потоков. 🆘

Мы занимались поиском причины на протяжении нескольких дней перед Новым Годом, ведь оставлять систему в таком состоянии на праздники было недопустимо. И вот, бьют куранты, шампанское 🍾 льется в бокалы , а я и дежурный админ пытаемся рездебажить и понять причину происходящего. Дебаг продолжился и в праздники, и еще недели после него. Что только не делали: статический анализ, анализ трафика, strace, смена ядер, замена сетевых карт, анализ кода ядра Linux и кода драйверов сетевых карт.

Это завязка истории которую я держал в заметках еще с марта 2018. В ней и борьба с собой, поиск решений без малейшего представления куда копать, работа в новых сферах и в сжатые сроки при постоянном стрессе. Не менее эпично ошибку фиксали, сделав из этого целый хакатон. Теперь пришло время историю поведать и лучшим местом для этого будет Highload Fwdays’19 что состоится 5 октября 2019 года в Киеве. Тем кто придет гарантирую полезный и увлекательный сторителлинг, отвечу на вопросу и понетворкаюсь.  Для жителей других стран и регионов будет организована онлайн трансляция ближе к мероприятию.

Для подписчиков канала специальный дискаунт. Используйте при оплате промокод MENSHIKOV и получите 15% скидки. Для тех кто оставит запрос в @noTieInIT_bot (в свободной форме) получит записанное видео с мероприятия.

Увидимся на конференции!

​​🎉 Панельная дискуссия с архитекторами

Отгремел Highload Fwdays'19 и пока готовятся видео докладов, то спойлерить историю не буду. Скоро будет, те кто запрашивали историю и писали боту обратной связи получат видео, слайды и сикрет бонус.

Вместе с тем поучаствовал панелистом на дискуссии по архитектуре и залил на youtube для вас запись с этой панели.

Два топовых вопроса по количеству голосов были:
🔸кто такой Architect и как им стать;
🔸про микросервисную архитектуру.

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

Относительно же микросервисов, то я еще 2 года назад писал об этом на канале. Вопрос и по сей день актуален, как показало голосование. Как отметил Макс Безуглый, разрезать систему на микросервисы - это искусство. Не всем и не всегда нужна сервисная/микросервисная архитектура, ты не Netflix и не Uber.

По стечению обстоятельств все члены панельной дискуссии, включая и меня, являются активными участниками International Software Architect Club, а Макс Безуглый - его основатель. Кстати, через несколько месяцев планируется релиз roadmap от клуба для инженеров готовых двигаться в сторону роли архитектора.

Все, хватит мне спойлерить, все детали на видео!

🛠Релиз после года разработки и debug под новогодний звон бокалов

Организаторы Highload Fwdays'19 уже обработали видео, а еще оно оказалось в открытом доступе, потому записью могу поделиться не только с теми кто писал боту запрос, но и всем подписчикам!

Видео: https://www.youtube.com/watch?v=4ZP3elDj5NY

Создание подобного материала и доклада довольно сложный процесс, ведь все нужно восстановить шаг за шагом, подготовить теоретическую базу, потому я был бы очень 😻благодарен за лайки😻 этого видео если оно понравилось, это придает силы делиться знаниями и дальше, говорит что это кому-то полезно и нужно! С радостью жду комментариев, пожеланий, обратной связи. Как под видео, так и боту.

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

👇 Остальные ссылки из видео и презентации 👇

📌 Тюнинг TCP стека и OS:
Red Hat Enterprise Linux Network Performance Tuning Guide
Performance Tuning on Linux — TCP
Tuning Linux to reach maximum performance on 10 Gbps network

📌 NIC tuning, IRQ, SoftIRQ
Лучшая публикация что я когда либо встречал по внутренностям ядра и работе ядра с NIC и т.п.

📌 Наш инструмент для замеров технических характеристик live видео потока: https://github.com/LCMApps/video-quality-tools
За звездочки на гитхабе тоже буду благодарен! Мы старались!

Приятно просмотра!

​​🥁 Meetup Об IT без галстуков: беседа с инженером Netflix о секретах успеха компании

10 ноября я провел свой первый в жизни митап, теперь “Об IT без галстуков” еще и митапы проводит! Уровень контента был задан еще самим телеграм каналом, потому митап точно должен был быть чумовой. Мне удалось договориться с Senior Software Engineer провести встречу и побеседовать о культуре Netflix, которая уже стала идеалом для многих компаний и для меня в том числе.

Буквально за 1 день удалось договориться за локацию, iHUB нам очень помог в этом, спасибо, за второй день подготовить промо и кампанию и за 5 дней до ивента запустилась новость о нем. Несмотря на короткий срок, за 2 дня было зарегистрировано 150 человек. О полном цикле и тонкостях проведения я поведаю позже, а пока...

Встречайте, часть 1 беседы. Текстовая версия в моем блоге и на русском, запись видео тоже в блоге, но на родном языке спикера, украинском. Да-да, кто-то слышал как я говорю на украинском языке?)

В этой части речь идет о:
🔸найме и этапах интервью в Долине и в Netflix;
🔸о технических заданиях в USA и в Netflix;
🔸взаимной проверке сотрудников и кандидатов, роли менеджера в найме;
🔸компенсационном пакете, акциях, опционах, RSU;
🔸о freedom and responsibility.

А еще спойлер. Референсы для устройства в Netflix и в Aurora в конце поста.

Читать или смотреть.

🥁 Meetup Об IT без галстуков: беседа с инженером Netflix о секретах успеха компании. Часть 2

Вторая часть митапа-интервью с Арсеном Костенко, senior software engineer Netflix. Для тех кто пропустил первую часть есть чудо ссылочка.

В этой части зафиксированы следующие поинты:
🔸культуре в Netflix;
🔸имеет ли инженер понимание зачем делается система? насколько глубоко?;
🔸вкладе менеджера и разработчиков в общее дело;
🔸метриках, SLA, agile и self management;
🔸об организации команд, межкомандном взаимодействии и коммуникацияхж
🔸PDP (personal development plan), оценки 360;
🔸снова о пересмотре дохода, хотя это было в части 1;
🔸DevOps и деплоймент в проектах.

Еще для затравки вставлю цитату из разговора. Она описывает подход в компании к зарплатной политике, ибо это больная тема… судя по количеству вопросов зала, личных вопросов мне, вопросов в комьюнити и в IT группах…

В Netflix есть такой момент. Если человек говорит: “Я хочу +50”, то они пытаются дать ответ на 3 вопроса: 1) что компания потеряет, если этот человек уйдёт? 2) сколько в среднем люди такого уровня получают? 3) сколько будет стоить компании нанять человека с похожим скилл-сетом на эту позицию? И часто мы говорим только про вопрос номер 1 - сколько я буду получать в компании или вообще в индустрии? Если кто-то получает в индустрии +200%, но для того, чтобы нанять человека на это место выполнять эту работу, ты можешь заплатить те же деньги и быстро нанять другого специалиста, сложно держать такого человека. Ты можешь зарабатывать больше. Возможно, у тебя есть скиллы, которые ещё не используются.

Читать часть 2.

🥁 Meetup Об IT без галстуков: беседа с инженером Netflix о секретах успеха компании. Часть 3

Последняя часть оцифровки митапа-интервью с Арсеном Костенко, senior software engineer Netflix.

В этой части:
🦀снова и снова о культуре в Netflix;
🦀тестировании;
🦀передаче знаний;
🦀дежурствах и SLA;
🦀о том для кого что явялется успехом;
🦀продолжительности жизни в компании и возрасте сотрудников;
🦀об иммиграции и будующем отечества.

Ссылки на все части: часть 1, часть 2, часть 3.

Приятного прочтения!

​​🐹 Дорогие мои, поздравляю с наступающим Новым Годом!

2019 был прорывной год по многим аспектам лично для меня. Я даже не побоюсь сказать, что это был переход на следующий ментальный уровень. В уходящем году я сам себе, на своем же примере, подтвердил высказывания Фридриха Ницше и Вольтера, повторил гравировку Соломона, но уже на своем сердце. Глупо утешать себя, что сюрпризы преподносимые жизнью будут только радовать... Но знаешь что я могу в этом ключе постулировать и одновременно с тем пожелать тебе? Самое главное в жизни - двигаться к намеченной цели и не сбиваться с пути. Желаю тебе в Новом 2020 Году не сворачивать и не терять этот путеводный маяк из видимости. Желаю больше жизненных сил и уверенности, дабы встречный ветер не мог тебя поколебать. Побольше единомышленников и сильных людей рядом, готовых подставить плечо и заменить лампу в маяке, если та угаснет.

С наступающим, друзья, всего вам наилучшего! С Новым Годом!

​​🍩 Куда идти работать в IT? Зачем нанимают людей? Глубинный мотив.

2 года назад я дал краткий очерк по логике принятия решений по повышениям персонала. За это время запросов... ну штук 5 было расширить эту тему. Давайте расширим, но начнем с типов компаний и дойдем до того какие же компетенции прокачивать и как работать чтобы стать ценным сотрудником и партнером. #личностноеразвитие

Самый фундаментальный вопрос. Зачем вообще нанимают людей? Рекрутеры всегда скажут про расширение, новые челленджи прочий бла-бла-бла, но мотивацию заказчика они не сдадут и тут подходить творчески надо и самостоятельно анализировать и задавать вопросы. Тип компании напрямую влияет на то как сложится развитие специалиста и его поощрение. Варианты глубинной мотивации ниже и это реальные примеры, а не надуманные (от этого еще страшнее становится). Я отсортировал пункты выше от наименее перспективного до наиболее перспективного.

1️⃣ Заказчик хочет получить себе откат. Если ты не знаешь определения, ну мало ли, может ты читаешь это из USA/EU и не сталкивался с постсоветским бизнесом, то такая категория заказчиков тратит корпоративные деньги и не ожидает даже что его работа будет выполнена в принципе. Что-то делается, что-то сдается в эксплуатацию, а кто-то на стороне заказчика новый Гелендваген себе подарит во время депрессии кризиса среднего возраста. Не стоит путать с компанией где просто нет плана и менеджмента, хоть они и близки.
2️⃣ У заказчика уже есть компания, но там текучка и нужно закрывать дырки после побега людей. С этим типом все понятно, скорее всего условия труда не очень, либо менеджмент настолько плох, приоритеты и вектор меняется, процессов никаких нет.
3️⃣ Менеджмент компании отстранился от управления и все движутся по проторенной дорожке, нанимая людей в надежде на вжух-вжух и что чудо произойдет, а компания не развалится (нет, развалится на лонг ране). Не путать с компаниями где менеджмент зашивается просто из-за отсутствия времени, но пытается/делает правильно.
4️⃣ Заказчик делает это ради статуса. Прикиньте, люди готовы тратить сотни килобаксов чтоб понтануться что у них есть собственная разработка, продукт и они IT бизнесмены, хотя не отрезают в этой сфере ничего от слова совсем.
5️⃣ Заказчику нужно минимизировать уплату налогов и затраты на IT разработку. Это обычно аутсорс/аутстаф и чем дешевле - тем лучше, если качество одинаковое. Если парит качество, то смотрят уже на компанию, команду, детально выясняют как будут тратить их деньги.
6️⃣ Расширение команды на старом проекте без плана экспансии и развития.
7️⃣ Точечная замена.
8️⃣ Расширение или формирование команды под новые проекты/задачи.

🍩 Куда идти работать в IT? Зачем нанимают людей? Глубинный мотив. Часть 2.

Продолжаем тему. С пунктами 1️⃣, 2️⃣, 3️⃣ всё понятно, для инженера что стремится получить опыт и стать профессионалом это не самый лучший путь. “Статусные” по типу 4️⃣ могут быть интересны для resume driven development: тут можно в резюме добавить k8s, docker и прочие технологии ради технологий. Иногда такие заказчики к аутсорсерам и аутстафферам приходят. Ну а что, ждать-то облом, а с пацанами в бане после охоты поговорить надо будет уже скоро. 5️⃣ - это аутсаф, аутсорс. Порой бывают хорошие проекты, порой - это монстры что легаси кодовую базу плодили 10+ лет, а авторы кода уже на пенсию вышли и внуков нянчат.


Старые команды (6️⃣) расширяют без цели развития когда проект/команда уже вышла на определенные показатели и осталось 80% времени на 20% рутины. В таких командах можно работать когда менеджмент хорош и все понимают что нужна стабильность и новшества не нужны. Такой себе вариант пенсионной программы чтобы сидеть ровно на пятой точке. Еще раз, стоит давать себе отчет, что инноваций не будет и максимум позволят порефакторить код. Обычно много бюрокаратии в таких компаниях и командах.

Точечная замена (7️⃣) может быть крайне интересной в плане развития. Советую выяснить причину по которой эта замена ищется и чем предстоит заниматься.

Расширение под новые проекты (8️⃣) может происходить как с выделением людей в отдельную команду, так и с включением людей в существующую команду для решения конкретных задач. В этих компаниях/командах обычно есть представление куда стоит двигаться и какие цели. Цели у них основное и если техническая команда профакапит реализацию, либо новый проект не выстрелит, то людей хороших переведут, а плохих уволят.

Пост довольно большой получился (опять), потому в следующей серии пойдет речь о том как же прощупать работодателя/рекрутера и выяснить тип компании и как составить план и где будут готовы платить и сколько. Ну и напомню, вопросы и предложения можно писать на @noTieInIT_bot. Кидайте свои истории работы в компаниях разного типа. Самые полезные и прикольные опубликую (можно анонимно)!

​​⚖️Приятно удивила статистика, что половина из вас, дорогие подписчики, работают в компаниях готовых рвать и метать. Держу кулаки за остальных, вы все можете и все в ваших руках.

Рекрутеры и люди участвующие в собеседованиях на стороне компании/заказчика всегда приукрашивают все. Давайте несколько типичных примеров фрода работодателей приведем.

🔗Развод на ставку. Договорились вы на сумму N, оффер скинули с этой суммой, а потом, внезапно, выплатили меньше. Частый случай, кстати, в последнее время. На второй странице оффера мелким текстом напишут, что зависит от перформанса и скорости выполнения работы и может быть пересмотрено. Вот и пересматривают. Я за последние 2 недели такое 2 раза видел, когда мы оферили кандидата в Aurora, его перебивали по ставке, накидывая немыслимые +0.7-1к. Меня, естественно, заинтересовало сразу какие это компании так жестко на повышение играют, ну и пробил по известным ресурсам. Те компании куда люди пошли на +1к уже были заляпаны в фактических выплатах меньше на 1.5к. Хорошая стратегия для однодневок, но наша деловая репутация безупречна и играть по таким правилам я не буду. Если кандидаты ведутся и так безрассудно себя ведут, не удосужившись даже проверить своего работодателя, то нам с ними точно не по пути. Но ты не забывай, что могут так прокинуть.

🔗Обещают золотые горы. Меня привлекали к паре таких кейсов, для разбора. CEO складно продает, обещает долю в компании, супер перспективы. Запрашиваю договор для ознакомления, а там нарушение конституции, нарушение законов в сфере признания авторства и передачи исключительных прав, наличие штрафов за разглашения чего угодно, без спецификации что составляет коммерческую тайну. Естественно, после общения с юристом второй стороны и предоставления перечня претензий человек растворяется и компания резко морозится начинает. Ну тут все понятно. Читайте договор, задавайте вопросы, смотрите как реагирует работодатель.
🔗Собеседует одна команда, а берут в другую. Такое встречается, когда вакансию и позицию продают одни люди, а потом работать начинаешь совсем с другими. Уточняйте к себе ли на проект берут собеседуют или нет. Если важно найти хорошую тимку, то запрашивайте общение с руководителем. У меня только 5% кандидатов задают этот вопрос. У меня в флоу только те люди собеседуют к кому ищутся кандидаты, руководитель всегда присутствует на собеседование и активно участвует. Исключением может быть только больничный или форс мажор и тогда собеседую я вместо TL/ментора.

🔗Понимания нет для чего нужен человек. Тоже очень редкий вопрос, но очень важный. Когда работодатель не может сформулировать перечень задач или не может озвучить направление которым надо будет заниматься, то это плохой знак. Скорее всего, там полный треш с задачами: их либо нет, либо обещают написать когда выйдешь, либо нечем будет заниматься (скорее всего, ибо не напишут когда выйдешь, ага), либо воткнут заниматься тем чем придется.

🔗Плохой менеджмент. Думаю тут все понятно, если позиция Senior, TL, Architect и выше, то обязательно общение с Product Manager, Project Manager, желательно с C-level. Кота в мешке покупать не стоит, какой бы не был крутой линейный руководитель на собесе, но если синергии нет с топами, либо топам по барабану на происходящее, то это не самый лучший знак.

🔗Развод на офис. Нынче модно стало выбирать работодателя по офису. Мне лично этот тренд непонятен и в моем мире ты устраиваешься на работу не чтобы любоваться новыми дизайнерскими решениями, но для многих важен. Обещают один, потом посадят в другой. Среди маленьких компаний я такое встречал, еще и кичились этим собственники маленьких галерок: снимали посуточно офисы в центре города, там собесили, а потом оферили и сажали в подвал. таким ещё и юристы/адвокаты балуются. Уточняйте, в каком офисе работа, в этом же или нет.

Был ли пост полезен? Шлите свои истории на @noTieInIT_bot, задавайте вопросы!

🏧Как застраховаться кандидату определили, можно и про мотивацию работодателя поговорить.

Золотое правило успешного бизнеса (внезапно) - сотрудник компании должен приносить больше пользы чем вреда, стоить меньше чем приносить дохода. Если перекос в числах наблюдается, то компания пойдет на дно. Конечно, есть исключения, например, некоторые IT гиганты остаются убыточными, но в них вкладывают деньги инвесторы, потому что ожидают дальнейший рост, верят что поглотит более крупный игрок, что найдут способ монетизировать этот бизнес. Но это ставки и игра по крупному, к СНГ относится в меньшей степени.

Потому, правило все еще работает: давать пользы больше и приносить больше пользы чем стоить. Как бы не хотелось многим высказаться в духе комментаторов "замечательного IT", мол "Мою работу продают в 2 раза дороже, потому требую в 2 раза больше", но это не будет работать. За ширмой мамкиных диванных экспертов остаются такие вопросы:
☀️уплата налоговов, как корпоративных, так и за сотрудников (надеюсь, скоро уйдет в прошлое оплата за сотрудников)
☀️аренда офиса
☀️найм персонала для обеспечения жизнедеятельности, например, уборщиц, офис менеджеров и тп
☀️расходы на командировки и конференции, на которые ходить хотят все, но не считают стоимость никогда
☀️расходы на поиск клиентов для аутсорса/аутстафа, затраты на неудачные эксперименты и провальные идеи, что применимо для продукта в большей степени и в меньшей для аутсорса и аутстафа;
☀️юридическое сопровождение, расходы на бухгалтерию и деятельность компании
☀️железо, клауд, etc

Потому, дорогие мои, чтобы окупить стоимость в $1k нужно бизнесу заработать минимум $2k, а чтобы расти и развиваться и того больше, $3k+ и тп. Когда в структуре продуктовой компании расходы на персонал выше 50%, то это тревожный звонок. А еще инвестор или собственник тоже хочет есть, он рискует и вкладывает деньги дабы заработать, а не обеспечить рабочими местами по доброте душевной....

​​🤬 Пока мы тут про компании перекашливали, подкрался мировой финансовый кризис.

Ранее я давал прогноз дальнейшего развития рынка IT на dou, но я и сам не ожидал что так быстро это произойдет. По-факту, коронавирус 😷 послужил отличным поводом чтобы запустить цепочку событий. У меня давно была идея запустить проект по финансовой грамотности и делиться с вами знанями, но пришлось последнюю неделю заниматься этим форсировано.

Встречайте, проект ФинВам посвященный финансовой грамотности. У него есть и телеграм канал свой, совсем юный - @FinVam. А еще есть youtube канал где уже первый видос, хоть материал готовили еще с января месяца… но как обычно, пришлось отложить штатный запуск и ковать металл пока горяч.

Кризис затронет и IT, то пошарю свои мысли, наблюдения, анализ на @noTieInIT. Подписывайтесь на канал в телеге, подписывайтесь на ютуб. Если контент нравится - рассказывайте друзьям, коллегам, родителям (еще и про B2B jewelry рассказывайте родителям 😭). Оставляйте камменты, предлагаейте темы. Приятного просмотра!

https://www.youtube.com/watch?v=L4v1N30Y2ak

Друзья! 11 апреля состоиялся стрим на тему рынка IT в кризис. Участсовало 4 серьезных гостя:
🔹 Евгений Лысенко, co-founder concert.ua, одного из крупнейших сервисов по продаже билетов на концерты и мероприятия;
🔹 Дмитрий Гринь, CTO Jooble, одного из крупнейших поисковиков вакансий;
🔹Андрей Никишаев, самый известный и один из лучших украинских экспертов по ML/AI;
🔹 Ирина Лисовская, лидер технического рекрутмента, автор YouTube канала Recruiter TechCamp, организатор множества HR конференций;
🔸Ну и я, Дмитрий Меньшиков, CTO Aurora Technologies, та вы и так знаете кто я 😉

Поговорили в френди атмфосфере про влияние кризиса на IT, про то как ведут себя собственники бизнеса и как это отражается на персонал, как не остаться без работы и какие скилы самые востребованные. Дима же видит всю эту статистику в Jooble, а Ирина знает настроения среди HR. Евгений в самом эпицентре негативного импакта, но он крайне умный и креативный парень, потому у него наверняка уже есть идеи трансформации концертного бизнеса. Андрей - эталон построения личного бренда и он ведёт свои курсы, расскажет нам как живёт на карантине онлайн образование, да и про образование в целом. А ещё он консультировал Fortune 500 компании и поведает какие компании будут эффективны в будущем и как будет миграция на ремоут происходить. Было интересно!

Во время трансляции мы отвечали на вопросы в комментариях аудитории из YouTube. Вещали на аккаунте @FinVam, ибо ютуб решил порезать мне трансляцию из-за перегруза. Ну и правда, на ФинВаме во много раз больше просмотров чем у моего личного аккаунта.

https://www.youtube.com/watch?v=5rERgFEyO7g&t=420s

🤬Массовая цензура в интернете! Google, YouTube, Facebook, Instagram занимаются цензурой и выпиливают мои публикации и видео, начиная от информации о масштабах пандемии, заканчивая постом какие маски помогают защитить себя и близких (рекомендации WHO, на минуточку, а не ересь вроде “пошей маску дома”.

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

https://telegra.ph/Cenzura-na-temupanedmii-v-internete-Google-FB-Insta-YouTube-04-14

Какой вывод? Мы давно в жопе. За нами следят каждый день, нам тарегтировано дают ту информацию, которую большой брат считает приемлимой. А что страшно знаете? Что мы не можем ничего сделать, если используем эти источники. Люди, как стадо, получают таргетированый контент, который алгоритмы fb и гугла подсунут. Это информационный пузырь, это искажение донесения новостей. Это цифровая диктатура. Остается лишь надеятся на телеграм, который пока никак не цензурирует контент…