Как немного облегчить себе жизнь при проектировании электроники?

GALILEO by Intel®. Честно взято тут (https://www.ema-eda.com/sites/ema/files/Constraint%20Management.zip)
GALILEO by Intel®. Честно взято тут (https://www.ema-eda.com/sites/ema/files/Constraint%20Management.zip)

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

Тут не будет каких-то секретных знаний или откровений. Просто опишу ряд приёмов, помогающих сэкономить на отладке немного времени и еще чуточку собственных нервов. Всё это по отдельности, очевидно, можно найти в сети в том или ином виде.

Всё нижеизложенное — ни в коем случае не истина в последней инстанции, а всего лишь частное профессиональное мнение автора.

И ещё. Если вы признаёте только ЭПСН-40, твёрдую канифоль и паяльный жир, накладываете колбаски герметика руками и трассируете в спринтлэйауте, скорее всего некоторые советы и идеи вам не подойдут, так что смело пропускайте их мимо и не тратьте своё время и нервы на доказывание того, что и так всё работает.

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

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

Посадочные места и трёхмерные модели

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

А что является таковой для печатных плат?

Правильно. Посадочные места ЭРИ!

Прежде всего, забудьте про такую вещь, как чужие посадочные места из непонятной (или понятной) библиотеки из интернета. Только своё, только хардкор! Да, это сложно, особенно, когда проектирование электроники — не ваша основная область деятельности. Но если вы хотите делать действительно качественную электронику — начните делать футпринты самостоятельно. Так в них будут ваши и только ваши ошибки, а не чьи-то чужие. Это не так сложно, особенно если пользоваться адекватными генераторами. Например, с недостатками бесплатной версии PCB Library Expert вполне можно мириться. Зато вы получаете посадочные по IPC из коробки. Вместе с адекватными трёхмерками. При этом, создавая свою библиотеку ЭРИ, вам лучше заранее договориться, как будут называться файлы. Логично, если вы рисуете посадочные по IPC, и называть их так же по методологии IPC. Вы ведь в курсе (да?), что те же конденсаторы, одинаковые по размерам в плоскости, могут иметь совершенно разную высоту, и иногда это может иметь решающее значение.

RESC100X50X40L25N
RESC100X50X40L25N

Почему это так важно? Следование рекомендациям IPC позволяет в большинстве случаев получить гарантированно адекватную пайку (для многих стандартных корпусов). Потому что люди старались, вкладывали свой опыт и знания в информацию, которая содержится в IPC-7351B и прочих документах этой замечательной организации (долой почти два с половиной часа времени и мои уши слегка подвяли от акцента Роберта, но оно того стоит, рекомендую!). Сколько моих плат было спаяно что вручную, что на конвейере в печи оплавления — практически не было проблем. При этом посадочные по IPC вполне годятся и для ручной пайки. Может при помощи ЭПСН вы их и не спаяете (на самом деле, сильно зависит от жала), но каким-нибудь клоном серии T12 — запросто!

Есть еще распространенный вариант: рисовать посадочное место по рекомендации производителя. Я так поступаю, если корпус не принадлежит к каким-либо стандартным и для него нет адекватного генератора.

Типичный пример нестандартного трындеца от TI
Типичный пример нестандартного трындеца от TI

Для совсем ленивых есть такие сервисы, как SnapEDA, Ultra Librarian и прочие, которые предоставляют вам услуги генерации посадочных мест, УГО и трёхмерок интересующих вас ЭРИ. Поскольку эти сервисы ориентированы на массовость экспорта, как правило, они не учитывают некоторых особенностей конкретных электрических САПР. Например, в SnapEDA невозможно выдать посадочные с площадками с закруглёнными углами. А переделывать сгенерированные из таких сервисов посадочные — то ещё удовольствие. Если берёте оттуда трёхмерки, обязательно проверяйте размеры. То же самое касается и 3D ContentCentral и GrabCAD. Сколько ни пытался оттуда что-то использовать в неизменном виде, всегда были расхождения по размерам.

Паяльная маска (слева) и импортированные из pdf контуры (справа)
Паяльная маска (слева) и импортированные из pdf контуры (справа)

Если производитель ЭРИ даёт в документации нормальный векторный чертёж своего изделия (вы же умеете на глаз отличать векторную картинку в pdf от растровой?), бывает чрезвычайно полезно перевести его в, например, dxf, который уже потом, как правило, можно импортировать в вашу любимую САПР, чтобы убедиться, что всё то, что вы понарисовали, соответствует действительности. Это альтернативный безбумажный (а не как советует замечательный Роберт) метод проверки адекватности вашего посадочного места. В комментариях к видео еще предлагают печатать для проверки не на бумаге, а на прозрачной плёнке, но это тоже такое себе. Что делать со статикой? Как быть, если компоненты ещё только в закупке и приедут недель через десять? В общем, спорно. Кстати, импортируя dxf, всегда хорошо проверять, а соответствуют ли расставленные размеры реальным (и дело не только в чудесных словах not to scale на чертеже из документации). Я так и не разобрался, откуда возникают ошибки в импортированных из pdf размерах, но это бывает. Поэтому проверяйте, проверяйте и еще раз проверяйте! На фото ниже дорогущий компас почему-то не работал. Интересно, почему?

Реальный косяк разработчика (выбран неправильный шаг площадок) с размерами из моей практики. И ведь было припаяно. Александр, если вы узнали свой дизайн, не обижайтесь, пожалуйста! И на старуху, как говорится
Реальный косяк разработчика (выбран неправильный шаг площадок) с размерами из моей практики. И ведь было припаяно. Александр, если вы узнали свой дизайн, не обижайтесь, пожалуйста! И на старуху, как говорится

Зачем вообще заморачиваться с трёхмерками в библиотеке? Всё очень просто: чтобы облегчить себе и коллегам проектирование корпуса и вообще любой сопутствующей механики. Намного проще при создании компонента сразу привязывать к нему модель, чем после трассировки всей платы натужно сопоставлять примененные посадочные места с имеющимися моделями. И опять же, не ленитесь использовать конкретные трёхмерные модели, а не единый условный конденсатор «0603» на всю пассивку 0603. К тому же, многие производители предоставляют трёхмерки своих изделий, по которым в том числе можно проконтролировать адекватность создания посадочного места.

Почти все современные электрические САПР умеют в том или ином виде генерировать трёхмерку. Её бывает полезно показывать сборщику перед монтажом. Иногда одного взгляда на неё хватает, чтобы понять какие-то нюансы.

Шёлк

Некоторые считают следующий совет колхозом, но лично я ничего колхозного в этом не вижу: делайте разный шёлк для резисторов и конденсаторов. Разумеется, это касается SMD комплектующих.

Догадаетесь, где у этого источника питания резисторы обратной связи?

Не идеальная плата, но работает
Не идеальная плата, но работает

Очевидно, что если на плате нет шёлка, то это не поможет. В основном такой шёлк полезен, когда осуществляется ручная пайка. Бывает, глаз монтажника замыливается, и площадки для установки путаются между собой. Или некоторые путают конденсаторы и резисторы (да-да, бывают и такие монтажники). На этапе отладки опытных образцов подобная маркировка существенно облегчает первичную диагностику сборки.

Ещё один совет по шёлку — старайтесь всегда и везде при необходимости расставлять дополнительный признак первого вывода. Будь это разъем, микросхема или транзистор, обозначение первого вывода всегда полезно. Причём, с годами я пришел к выводу, что наиболее удобным символом для этого является равносторонний треугольник, а не точка, плюсик или что там еще иногда рисуют.

Вот смотрите:

Шёлковые треугольники
Шёлковые треугольники

Вполне очевидно из фотографии, где первый вывод у разъемов и транзистора. А если бы это были просто три точки? Ну…. может быть и было бы понятно, но шёлк не всегда бывает хорошего качества и иногда намеренную точку можно спутать просто с условной кляксой.

opt3001
opt3001

Что делать, когда шёлк нет смысла заказывать, а показать первый вывод хочется? А всё просто. Переносите треугольник в слой меди (или вскрытия маски). Разумеется, если окружающее пространство позволяет. Ещё один удобный приём, когда вы планируете заказывать шелкографию: рисуйте на многоногих разъемах не только первый вывод, но и с определённым шагом номера других выводов. При отладке устройства это очень облегчает тыканье осциллографом, поскольку вам не приходится вручную отсчитывать какой-нибудь семьдесят третий вывод от начала или считать, какой он там будет по порядку с конца, если в разъеме у вас 120 контактов.

Как было спроектировано и как получилось. Напаянное всё уже в работе, но смысл понятен
Как было спроектировано и как получилось. Напаянное всё уже в работе, но смысл понятен
Это разъем для UART. Сами разберётесь, почему земля в центре, а не сбоку?
Это разъем для UART. Сами разберётесь, почему земля в центре, а не сбоку?

Т.е. вам, практически, не требуется монтажная схема. Достаточно будет только электрической принципиальной с подписанными номерами контактов. Что делать со сквозными разъемами? Меня очень расстраивают печатные платы, на которых первый контакт в разъемах никак не обозначен отличающейся по форме медью. Ведь сразу очевидно, где тут первый контакт. Это бывает очень полезно при отладке в полях, когда плата установлена в корпусе, вы в форме буквы зю изогнулись со щупом осциллографа и еле подлезаете к разъему, а шёлк-то остался с другой стороны и вы, подсвечивая себе зиппой, думаете — а где же тут первый вывод в разъеме? С таким никогда не запутаетесь. Кстати, буду очень признателен, если кто-нибудь в комментариях объяснит мне смысл овально-вытянутых eagle-style площадок для выводных разъемов. Я вот как-то до сих пор этого не понимаю.

Порядок слоёв

Как было и как сделали
Как было и как сделали

Вполне понятно, что если вы делаете двухслойку, то скорее всего герберы (я очень надеюсь, что в производство вы отдаёте герберы, а не проекты) имеют имена для меди вида TOP\BOT или Верх\Низ и тому подобное. А как убедиться, что вашу заметку о том, в каком порядке идёт медь, технолог прочитал? Или что банально слои не перепутали местами? У меня было несколько раз такое. Благодаря описанному ниже способу, завод без особых проблем и проволочек признавал брак и переделывал всё за свой счёт. Приём прост и эффективен. Добавляйте номера слоёв прямо в медь. Вот очередной пример слева. Вверху показано то, как это спроектировано, а далее вид сверху и снизу. Не забывайте делать вскрытие маски в месте размещения такой маркировки. При необходимости для просвечивания пользуйтесь фонариком. Да, разумеется, всё зависит от толщины слоёв диэлектрика, но, как правило, всё достаточно хорошо видно на четырёхслойках. На шестислойках просто с цифрами всё уже гораздо хуже. Что делать в таком случае? Лесенку. Типа вот такой:

Лесенка из меди (https://dornerworks.com/blog/pcb-stacking-stripes-could-change-the-way-you-look-at-hardware)
Лесенка из меди (https://dornerworks.com/blog/pcb-stacking-stripes-could-change-the-way-you-look-at-hardware)

И вот как это выглядит на реальной плате:

Вид торца печатной платы (https://resources.altium.com/p/pcb-design-test-test-structures-and-types-tests-part-1)
Вид торца печатной платы (https://resources.altium.com/p/pcb-design-test-test-structures-and-types-tests-part-1)

Очень рекомендую прочитать статью в блоге Altium и посмотреть видео из другой статьи. Сам пока что такие лесенки не делал, поскольку в основном всё, что делаю, — двухслойки и четырехслойки. Очевидный минус таких лесенок заключается в том, что многие производители крайне не любят фрезеровать медь той фрезой (тупится, видать, и задиры остаются), которой выгрызают контур печатной платы. И отдельно пишут о том, что между фрезеруемым контуром и ближайшей медью должно быть определённое минимальное расстояние. Но, полагаю, если обратить внимание технолога на то, что в проекте так специально заложено, никто особо возражать не будет.

Инженеры из Gigabyte (http://www.xtremesystems.org/forums/showthread.php?267340-Sandybridge-for-overclocking-two-solutions-review) одобряют. Такую же маркировку я наблюдал и на некоторых материнках Asus
Инженеры из Gigabyte (http://www.xtremesystems.org/forums/showthread.php?267340-Sandybridge-for-overclocking-two-solutions-review) одобряют. Такую же маркировку я наблюдал и на некоторых материнках Asus

Выравнивание

Хотя сам монтаж — это совсем отдельная тема, стоит упомянуть про вещь, которая может его немного облегчить.

В идеальном мире есть схемотехник, тополог, SI, PI и многие другие инженеры, которые по-хорошему должны работать над проектом. Но, жизнь часто вносит свои коррективы, и иногда паять, трассировать, моделировать и многое другое делать приходится самому (да-да, колхоз как он есть!). А когда в проекте есть ЭРИ, которые из-за размеров, веса или технологии пайки не смогут нормально гарантированно самоцентрироваться из-за поверхностного натяжения припоя, хочется изначально установить их максимально точно. Хорошо, когда есть специальный манипулятор для установки компонентов. А что делать, когда есть только пинцет, да и тот вовсе не вакуумный?

А есть вот такой приём:

Вскрытие маски по углам под корпусом (слева), оно же с периметром корпуса (центр), как это выглядит в ортографической проекции в 3D (справа)
Вскрытие маски по углам под корпусом (слева), оно же с периметром корпуса (центр), как это выглядит в ортографической проекции в 3D (справа)

Идея очень проста: в углах компонента делаем вскрытие паяльной маски (если позволяет окружающая топология, очевидно). Ширины линии вскрытия в 0,15мм вполне достаточно. Поскольку точность совмещения при производстве печатной платы слоёв маски с медью существенно лучше точности совмещения меди и шёлка, то можно надеяться, что вскрытые уголки будут на своём месте. С шёлком такое иногда не прокатывает, особенно на многорядных BGA корпусах, когда сместил всё на 0.5мм и уже промахнулся на целый ряд. Очевидно, что надо понимать, для какого т.н. material condition вы делаете свои модели и посадочные места, для nominal или maximum (я всё делаю для nominal) и, соответственно, можно ожидать, что уголки будут работать не всегда идеально.

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

Как с этим работать в реальности? А очень просто. Вы нанесли пасту через трафарет (не экономьте на трафарете, кстати!) и начинаете расставлять комплектующие. Вместо того, чтобы с одного захода сразу опускать и придавливать компонент на пасту, аккуратно опускайте его на поверхность пасты и, обсматривая с углов, добивайтесь максимальной симметричности расположения. И только после этого прижимайте компонент к пасте, тоже не усердствуя, чтобы не сдвинуть. Как правило, если паста третьего типа, не просрочена и не бодяжилась самодельным флюсом, суспензия будет совсем слегка пачкать площадки компонента. При необходимости до прижима можно даже снять компонент и не перенаносить пасту и не чистить площадки компонента.

И последнее, но далеко не последнее

А то будет как тут https://www.eevblog.com/forum/projects/silk-screen-on-exposed-pcb-pads
А то будет как тут https://www.eevblog.com/forum/projects/silk-screen-on-exposed-pcb-pads

Проверяйте герберы, которые отправляете на завод, не ленитесь! Я не буду советовать конкретный софт здесь, поскольку есть много разных просмотрщиков с разной сложностью использования и задачами, которые они могут решать. Лучше, если вы смотрите герберы не в той же программе, которая их генерирует. Ну так, на всякий случай. Наверное, очень здорово, если в таком просмотрщике можно что-то измерить (те же минимальные зазоры и толщины, например, чтобы убедиться, что ваша плата соответствует определенному классу точности). Сверка герберов даже чисто визуально помогает избежать глупых ошибок. Вы инженер, который проектирует печатную плату. Технолог на заводе в общем случае не обязан за вас думать. Его задача — изготовить вам плату максимально близко к тому, что вы прислали. А уж что вы там напроектировали, это не его забота. Может вам так надо.

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

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

Stay tuned, как говорится!

ссылка на оригинал статьи https://habr.com/ru/post/544176/

Google Pixel 3 в 2021 — актуален ли?

Сегодня у нас на эдаком обзоре и вперемешку отзыве телефон, который покорил всех далеко не своим дизайном — Google Pixel 3.

История покупки девайса

Для начала, хотел бы сказать, что я люблю постоянно менять смартфоны ибо они быстро надоедают. Но год назад, мониторив ОЛХ (аналог Авито в Украине) я набрел на девайс за очень вкусную цену, о котором я мог только слышать — Google Pixel 2. Проблема была в выгораниях, которые меня далеко не смутили и решительно его купил за целых 2000 UAH (на момент написания статьи 5 347 российских рублей). Я далеко не глуп в спеках смартфонов, поэтому меня заманил когда-то флагманский Снап 835 и чистый андроид. Спустя пару месяцев обменял с доплатой на «старшего брата» в виде 2 XL и, наконец собрав лишнюю денюжку — купил девственный Pixel 3. Я был безумно доволен данным телефоном (не без изъянов, конечно) и вот почему:

Внешний вид

Мягко говоря, дизайн — его слабая сторона. Даже по меркам его времени. Большие рамки на чёлке и подбородке ( про версию 3 XL я вообще молчу, Боже сохрани), нестандартное размещение кнопок питания и громкости, всего лишь один модуль камеры, о котором мы поговорим позже. Одним словом, ну не тянет он на звание красивого смарта, а на флагман вообще не похож. Зато, как неосведомленные люди удивляются, когда этот, на вид, бюджетник, дает фору всяким Редми, Риалми и прочим среднебюджетным китайцам.

Начинка

Внутри нашего обозреваемого таится когда-то великий Qualcomm Snapdragon 845 и видеoускоритель Adreno 630. Все это посыпано всего лишь 4 Гб RAM, с которых владельцы помойных Редми вечно смеются, хвалясь своими 6-8 Гб ОЗУ. Но, назло таким людям скажу, дело же не только в сочных характеристиках, а и в ОПТИМИЗАЦИИ.

Хотя, о чем я говорю, Xiaomi о такой вещи не слышала)0)))

И этой начинки вполне хватает для всех целей. Серфинг браузера и Ютуб? Л-легко! Соцсети и мессенджеры? Раз плюнуть! Тяжелые игры? Врубай на максималках!

Я не вру. Ресурсов этого девайса хватает за глаза в абсолютно любом сценарии.

Система и оболочка

Мой экземпляр работает на Android 11( на которую, кстати, даже телефоны этого года не все перешли) с фирменной «чистой» оболочкой. То бишь, интерфейс тут выглядит так, как гугл велел. Одни из самых приятных анимаций даже на сегодняшний день, плавность в работе, скорость открытия приложений. Да, это все про Пиксель. Не даром данную линейку смартфонов считают «Iphone среди Android-устройств». Телефон действительно при своем не много говорящем внешнем виде даёт понять, что внутри скрывается огромный потенциал. Но теперь давайте по-честному: Андроид остается Андроидом. Это неизбежно и никак не исправишь. Каким бы классным не был интерфейс, насколько бы не была хорошей оптимизация, со временем он теряет силы. С пикселем ситуация та же. Все работает так же хорошо, никто этого не отрицает, но уже начинают пролетать фризы, аномалии с анимацией, баги и лечится это только сбросом. И то ненадолго.

Звук

И на втором, и на третьем Пиксле одинаково расположены стереодинамики. Моя оценка звука субьективна, так как они уже просажены. Звук хорош, его достаточно, чувствуются высокие и низкие частоты, но это все, что можно о нём сказать. Очень разочаровывает отсутствие Мини-Джека для наушников, он есть только на 3А версии.

Дисплей

В подопытном стоит P-OLED матрица, которая очень хороша по цветопередаче и черному цвету, но имеет ряд недостатков. Не знаю, во всех ли пикселях, или просто на моем просела яркость, но ее недостаточно. Весь день хожу с максимальной яркости, на улице при солнечном свете её крайне мало. Так же раздражает шлейф при листании, особенно заметно на черной теме. Прям очень раздражает. Мерцаний не замечено, а может я просто привык.

Износ материалов корпуса

Задняя крышка очень устойчива к царапинам. Всё время ношу без чехла и до сих пор ни одной крупной царапины, да и микроцарапин мало. Намного хуже дела обстоят с гранями и защитным стеклом. Типичная проблема с гранями перекочевала с Самсунг и на Пиксель. Они очень легко бьются и царапаются, пластиковое покрытие слетает до металла и оставляет неприятные точки серого цвета. На защитном стекле хоть и Gorilla Glass, но это не спасает. Экран весь в микроцарапинах и это жутко некомфортно при выключенном дисплее.

«Фишки » устройства

Тут пройдемся по нумерации:

  1. Active Edge

Как по мне, сжимаемые грани — очень полезная штука. Невероятно удобно вызывать Ассистента простым сжатием телефона. Так же, с помощью сторонней программы можно перенастроить на запуск любого приложения или скрипт.

2. Выделение текста и поиск по фото прямо из меню многозадачности

Невероятно удобная функция, особенно там, где копирование текста невозможно, например, пост в Инстаграме. Таким же образом можно сразу найти или перевести выделенный текст. Так же доступен поиск по фото, изображенного в приложении (данная функция работает в приложении камеры). Просто открываешь многозадачность, зажимаешь на фотографии и все, Великий Гуголь найдет тебе соответствия.

3. AoD (Always on Display)

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

Ну и по мелочам:

4. Водонепроницаемость по стандарту IP68

5. Безлимит в Google Photos

6. Беспроводная Зарядка

Самое вкусное — камера

Я не буду приводить конкретные примеры или сравнения с другими телефонами, нужно просто взять и проверить самому. Она шикарна. Я не могу сказать, что она обходит S20 ultra, Huawei P40 или IPhone 12 Pro Max. На их фоне старичок уже не способен с ними тягаться. Но в ней что-то есть. Она передает реалистичное изображение, качественный HDR, портретный режим, ну и конечно же, Ночная сьемка. Тут наш пенсионер уже может задать планку даже новым фото-флагманам. Если говорить просто, то дневные фото на уровне IPhone X/XS, а ночные вне конкуренции. Они не самые лучшие, но и не самые худшие. Все совершенно рандомно, как ИИ отыграет. Может сделать снимок лучше многих флагманов, а может его испортить. А вот если Ты, мой дорогой читатель, любитель инстасторис, то я разочарую. Видео тут по сравнению с Яблоками плохое. Шумы, либо наоборот мыльный шумодав, фризы при загрузке сторис из галерее. Одним словом, точно не для блогера.

Итоги. Все «за» и «против»

Я смело могу рекомендовать Google Pixel 3 к покупке, если вы согласны на все минусы и плюсы, которые будут описаны ниже

Итак, достоинства:

  • Производительное железо даже по меркам 2021

  • Голый Андроид с невероятной плавностью и скоростью работы

  • Великолепная камера, которая способна на многое по сравнению с бюджетниками/среднебюджетниками за эту цену

  • Аппаратные фишки вроде Active Edge, AoD и водонепроницаемость

  • Миниатюрный дизайн (если для Вас это минус, приглянитесь на 3 XL)

  • Поддержка Android 12 в будущем

  • Стереозвук

  • Беспроводная зарядка

  • NFC

А теперь, изъяны:

  • Троттлинг при продолжительной нагрузке

  • Недостаточная яркость дисплея и шлейф при скроллинге

  • Слабая батарея

  • Нет разъема под наушники

  • Медленная обработка снимка, особенно ночного

  • Неустойчивость к царапинам экрана и граней

  • Неактуальный дизайн

  • Рамки на подбородке и чёлке

Ну а на этом всё, дорогие друзья, хотел бы увидеть ваше мнение или опыт владения смартфонами от Корпорации Добра.

Так же не забываем о конструктивной критике по поводу статьи и прошу указать на ошибки, если они где-то есть

ссылка на оригинал статьи https://habr.com/ru/post/544474/

Где работать в ИТ в 2021: Lad

Герой сегодняшнего выпуска — ИТ-компания Lad, системный интегратор из Нижнего Новгорода. В этом году ребята впервые получили оценку и попали в наш рейтинг компаний. Сотрудники оценили Lad на 4,5 из пяти, особо отметив современные технологии, комфортные условия труда и отношения в коллективе. 

Чтобы узнать обо всем подробнее, мы расспросили Романа Андронова (заместитель генерального директора Lad) и Максима Теричева (технический лидер Центра разработки Lad). Они рассказали нам о жизни компании, о найме и адаптации новых сотрудников, о технологиях и о том, что коллективное пение — самое лучшее средство от выгорания.

Оценивая своих работодателей на Хабр Карьере вы помогаете нам делать рынок труда в ИТ более открытым и прозрачным!

оценить работодателя

Навигация по статье:


О компании

Lad — IT-компания и системный интегратор из Нижнего Новгорода. Занимается внедрением, доработкой и поддержкой клиентских проектов. Компания работает с клиентами из производства, строительства, торговли, атомной промышленности. А ещё ребята разрабатывают собственные проекты: веб-сервисы, приложения для мобильных платформ и IT-экосистемы. В компании работает около 500 сотрудников. 

Вот оценка компании Lad в деталях, а почитать комментарии сотрудников можно здесь.

Оценка Lad на Хабр Карьере в 2021 году
Оценка Lad на Хабр Карьере в 2021 году

Об условиях работы

Какой в вашей компании сложился рабочий график и какое отношение к переработкам? 

Роман Андронов: У нас принят гибридный рабочий график. Он формируется лидом и командой, исходя из целей и задач, а также учитывая личную ситуацию сотрудника. Если у работника есть дети, он далеко живет от офиса или проходит дополнительное обучение в вузе или на курсах, то мы идем навстречу и формируем удобный индивидуальный график. 

В целом, в у нас гибкое начало дня, большая часть сотрудников работает с 8:00 или 9:00, но есть и те, кто начинает рабочий день с 7:00. Работники без преград берут административные на один-два дня. Хотя это не всегда удобно компании, мы с пониманием относимся к таким случаям. Без проблем отпускаем работников на несколько часов в течение рабочего дня по личным делам.

Какие бытовые условия ждут нового сотрудника на рабочем месте? 

Роман: Мы обеспечиваем нового сотрудника техникой для офиса или удаленной работы. У нас есть специалисты, которые трудоустраиваются сразу на дистанционный формат, прописанный в договоре. Каждый получает от компании ноутбук или стационарный компьютер, гарнитуру, мышку, приветственный welcome-pack с мерчом: кружкой, блокнотом, носками, стикерами и разными развлекательными аксессуарами.

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

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

Формат помещений тоже разнообразный и многофункциональный. У нас есть опенспейсы на 30-50 рабочих мест, офисы на 5-10 сотрудников, кабинетная система. Мы создали комплекс переговорных комнат и учебных классов на разное число участников (от 4 до 35), которые бронируются через Google-календарь. Недавно запустили большой образовательный комплекс, состоящий из учебного класса, коворкинга, который трансформируется в переговорную комнату, лаунж-зоны и собственной кухни с зоной для кофе-брейков.

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

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

Есть ли возможность удаленной работы? 

Роман: С весны 2020 год на удаленке работает около 80% наших сотрудников. И, судя по всему, такой формат взаимодействия сохранится в будущем. Мы планируем постепенно уходить от закрепленных рабочих мест и переформатировать офисы в коворкинги. 

Какой социальный пакет получают сотрудники? 

Роман: Мы в прошлом году запустили пилот по ДМС, в котором участвовали все желающие, но после анкетирования сотрудников и анализа статистических данных сервиса, который предоставлял услугу, поняли, что деньги расходуются крайне неэффективно и отказались от ДМС. Решили организовывать локальные корпоративные предложения — например, скидки в стоматологическую клинику.

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

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

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

А еще, на день рождения сотрудника компания дарит оплачиваемый выходной день или небольшую денежную сумму по выбору именинника.

Какие бонусы, премии и компенсации предусмотрены в компании? 

Роман: Топ-менеджмент ежеквартально получает часть от прибыли компании. В каждом подразделении своя система оплаты и KPI, но практически везде есть квартальные премии. Регулярно запускаем проекты по геймификации с премиальным фондом.

Какие есть перспективы для образования и личного развития у сотрудников?

Роман: Абсолютно каждый сотрудник имеет возможность инициировать собственное обучение по согласованию со своим руководителем. Как правило, компания оплачивает 50% стоимости обучения. Если затем сотрудник организовал передачу полученных знаний коллегам или внедрил что-то, то компания возвращает ему 50%, которые он потратил. Если обучение организуется по инициативе компании, то оно всегда бесплатно. Сейчас у нас момент запущено бесплатное полуторогодовалое обучение 72 лидеров компании по soft skills.

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

Два раза в год у нас проходит ассессмент, на котором мы оцениваем как soft, так и hard skills, строим индивидуальную траекторию профессионального развития сотрудника. При этом учитываем потребности проектов, общие технологические тренды и личные предпочтения разработчика. 

О найме

Во сколько этапов проходит найм и что на них ожидает соискателя?

Роман: Мы выстраиваем динамичный процесс в найме, и он состоит из двух этапов. Сначала пишем кандидату в Телеграмм (реже на почту), задаем несколько вопросов и выявляем его интерес. Если обнаруживаем необходимый уровень заинтересованности в вакансии, то приглашаем на встречу. Интервью проводим в Zoom или Google-meet. На встрече присутствует эйчар, тимлид и техлид. Рассказываем про компанию, проекты и продукты, спрашиваем кандидата о его опыте, пожеланиях в развитии, обязательно проверяем на предметные знания. Обычно интервью длится около полутора часов. Если кандидат нас устраивает, составляем оффер и отправляем через мессенджер или на почту. Дальше будущего работника ожидает оформление в отделе кадров, велком-пак, общение со специалистом по адаптации, знакомство с коллегами и 12-месячный онбординг.

Даете ли вы тестовое задание кандидатам? Как оно устроено?

Максим Теричев: Техническое задание мы даем редко, только если есть сомнения. Чаще это бывает, когда ищем начинающих специалистов. Обязательно проводим техническое собеседование. Оно схоже с технологией ассессмента и устроено таким образом, что позволяет достаточно полно увидеть и понять технические навыки. Благодаря такой встрече мы четко понимаем, на какой ступени развития находится специалист.

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

Как отличается подход к найму в зависимости от позиции и стека?

Максим: От уровня специалиста зависит кто будет оценивать его навыки и наши ожидания. Для каждого уровня техническое собеседование устроено по-разному. От джуниор-разработчика мы ждем базовые знания технологий и предлагаем решить несколько небольших задачек прямо на собеседовании. От высококвалифицированных специалистов — ответы на открытые вопросы и хорошие взвешенные размышления по теме разговора.

Какая фраза от кандидата на собеседовании точно заставит вас выкинуть его резюме?

Максим: Вычеркнем кандидата, если поймем, что этот человек способен идти по головам. 

Кого последнего вы уволили и почему?

Максим: Недавно уволили разработчика, человек очень сильно «выгорел». Мы 1,5 года пытались исправить ситуацию и помочь ему вернуться в рабочее русло, но не получилось. У нас не принято увольнять людей, мы стараемся найти им место и интересный функционал, если чувствуем, что сотруднику стоит временно или на постоянной основе поменять функционал. Мы переводили этого специалиста на другой проект, проводили встречи и разговоры 1:1, но это не помогло… Допускаем, что здесь есть и часть нашей вины, но, с нашей точки зрения, мы предприняли все попытки вывести его на нужную нам производительность. 

Как происходит онбординг нового сотрудника?

Роман: У нас есть специальный сотрудник — менеджер по адаптации, который встречает всех новичков, вручает welcome-pack, помогает в оформлении, проводит экскурсию по офису, показывает сервисы, на которых мы работаем, дает всю необходимую информацию о правилах и нормах компании и знакомит с командой. Планируем внедрить приложение, которое будет носителем необходимой информации для новичка. 

В команде нового сотрудника встречает ментор, он с технической точки зрения рассказывает о проекте, в котором будет работать этот сотрудник, о коммуникациях внутри коллектива и о задачах на ближайшее время. Дальше адаптацией занимается эйчар: вместе с руководителем прорабатывает ИПР нового сотрудника. Регулярно проводим встречи: по итогам первой недели, месяца, двух месяцев, по окончании испытательного срока, по прошествии 6 и 12 месяцев. Кроме этого, сотрудник после первого месяца проходит welcome-тренинг, на котором ближе знакомится с первыми лицами компании, с другими новичками и компанией. 

О команде

Какая методология разработки у вас используется и почему?

Максим: У нас Agile. Водопад (и иже с ним) на тех рынках, для которых мы разрабатываем, — слишком неповоротливая конструкция. Для проектов на поддержке используем Kanban, для новых проектов — Scrum, ну или точнее ScrumBut. Например, не всегда по итогам спринта рождается инкремент, или можем запросто задеплоить готовый функционал в середине спринта.

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

Каковы размеры и структуры команд?

Максим: Команды разные, от 5 до 30 человек. Структура плоская. У нас нет тимлидов, потому что, как правило, тимлид — это хороший разработчик, которого зачем-то нагрузили административной работой. У нас есть отдельный техлид проекта (иногда части проекта — бэкенда или фронтенда) и проджекты, которые берут на себя административную работу. В нашей структуре есть продакт-оунер или команда продакт-оунеров, которые определяют, что делать в будущих спринтах.

По каким критериям вы разбиваете разработчиков на джунов, мидлов и синьоров?

Максим: Тут нужно сразу сказать, что осмысленно мы к этому процессу начали подходить где-то год-полтора назад, и еще не до конца докрутили в нем все, что нам бы хотелось. В целом сейчас мы пересматриваем грейды раз в полгода (в апреле и сентябре) и подходим к этому с трех сторон:

  1. Мы разработали список того, чем, по нашему мнению, положено заниматься разработчику на том или ином уровне. Например, один из пунктов для хорошего джуна — он ДОЛЖЕН задавать много вопросов (мы специально фокусируем на этом внимание, чтобы снять у людей блок на этот счет). Для мидла важно участвовать в командном code review и менторить джунов. Для сеньора — участвовать в проработке архитектуры и отвечать на вопросы. Разумеется, это только примеры и список для каждого уровня достаточно большой. Перед ассессментом техлиды направлений оценивают каждого из своих разработчиков по этому списку.

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

  3. Лиды гильдий или техлиды смежных проектов проводят техническое интервью разработчика, на котором мы проверяем его фактические знания.

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

Кто чаще возглавляет команды — продуктовый специалист или технический?

Максим: Обычно это все-таки симбиоз этих двух людей. Их доли в управлении чаще зависят от их софт-скиллов и пожеланий. В каких-то командах продакт просто передает бэклог техлидам и проджектам, и они уже дальше сами ведут работу. В других — продакт очень близок к команде и держит руку на пульсе, а техлид подключается по мере необходимости для проработки сложных вопросов.

Как часто люди меняют команды?

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

Что важнее, софт-скиллы или хард-скиллы?

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

Как много собраний у вас проводится? Есть ли особые подходы к ним?

Максим: Помимо обычных планирований спринта / дейликов / демо / ретроспектив, у нас есть практика ежемесячных собраний для всех сотрудников компании. На них мы рассказываем о новых продуктах, результатах работы существующих проектов и направлений, открытых вакансиях, возможностях карьерного роста, бенефитах для сотрудников. На встречах выделяем время на вопросы сотрудников.

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

Как вы боретесь с выгоранием сотрудников?

Максим: Мы поем 🙂 Да-да, если ощущаем, что команда устала и пора отдохнуть, то берем гитары и устраиваем «Акустик Сейшн». Кроме того, бывают обычные выездные посиделки с пивом и пиццой. Сейчас из-за эпидемиологической ситуации это сделать сложнее, но мы не унываем и задумываемся о немногочисленной встрече с соблюдением дистанции. Для тех, кто не поёт есть альтернатива — игры в настолки. Проводим встречи один на один, это очень помогает сотруднику рассказать о трудностях, поговорить по душам с лидером. Есть и ещё несколько правил, которых мы стараемся придерживаться.

  • Мы не «грубим» с переработками. Где-то год назад, в самом начале ковидной истории, была необходимость в жестких кранчах, но сейчас мы снова вернулись в штатный режим и переработки на наших проектах — очень редкое исключение.

  • Мы не против, если разработчик хочет попробовать себя в чем-то другом. Благо единый язык позволяет нам относительно безболезненно переводить людей между фронтом / бэком / мобильной разработкой при их желании. Разумеется, продвинутый фронт-разработчик не станет сразу полноценным бэком и наоборот, но для нас важно, чтобы люди занимались именно тем, чем им нравится.

  • Мы следим за отпусками и активно мотивируем людей уходить на отдых.

О технологиях

Какие языки, фреймворки и библиотеки используются на проекте?

Максим: На проектах основной язык — TypeScript. Это позволяет нам выстраивать единообразную траекторию обучения на начальном этапе и дает возможность легко проводить ротацию сотрудников при их желании. На TypeScript пишем и бэк, и фронт, и мобильные приложения. Два основных бэк-фреймворка — Hapi и Nest. На фронте —- React. На мобильных приложениях — React Native. В качестве основной базы данных для большинства проектов используем PostgreSQL.

Что вы можете рассказать об архитектуре проектов?

Максим: Чаще всего это микросервисы, которые общаются между собой через NATS или RabbitMQ. Также в копилке есть пара решений на Kafka. Но есть и монолиты. Обычно это проекты на начальной стадии развития, когда все может стремительно меняться. Сейчас стараемся почетче бить монолиты на модули, чтобы потом можно было малой кровью выносить модули в отдельные сервисы. Для этого начали плотно использовать шаблонизаторы и генераторы кода, например Hygen.

Какая у вас принята политика код-ревью?

Максим: Сильно зависит от проекта, но, в основном, код-ревью делают два человека, причем один из них должен быть экспертом в этой области проекта.

Как тестируется код?

Максим: С юнит-тестами все сложно. У нас достаточно сильный отдел QA, который отлавливает львиную долю багов. На части проектов внедряем BDD и автоматическое интеграционное тестирование. В целом бэк значительно лучше покрыт тестами, чем фронт и мобильная часть. 

Насчет ручного тестирования — процесс может немного отличаться от проекта к проекту, но в целом он примерно такой:

  1. После выполнения задачи сотрудник передает ее в QA, и QA тестируют ее на дев-контуре.

  2. Собранный релиз едет в стейдж, где QA плотно прогоняют все собранные в релизе задачи, а также проводят экспресс-тестирование всего остального функционала (как бы чего не сломалось).

  3. После релиза на прод QA проводит экспресс-тестирование всего сервиса, чтобы убедиться что релиз прошел штатно.

Как устроен процесс документации и ведения базы знаний на проектах?

Максим: Когда команда 10-15 человек, над документами особо не задумываешься, но когда она вырастает до 80, этот вопрос встает ребром. За последний год наша команда разработки увеличилась в 2,5 раза, и сейчас мы начали структурировать и систематизировать работу с документацией. Формируем гильдию технических писателей. По ведению документации есть два основных направления:

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

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

Документацию, как и работу с задачами, ведем в YouTrack.

Каков процент легаси-кода на проекте и как часто разработчики занимаются его рефакторингом?

Максим: С учетом нашего быстрого роста, легаси-кода пока не так уж много. Есть некоторые сложности в мобильной разработке в связи с обновлением React Native и совместимости библиотек. В целом, мы гораздо больше пишем нового кода, чем поддерживаем легаси. Но если разработчик объявляет, что нужно зарефакторить ту или иную часть, продакт и техлид решают насколько это может быть важно для проекта и при необходимости ставят задачу в бэклог. 


Оценивайте своих работодателей на Хабр Карьере и рассказывайте, как вам там работается. Эта оценка останется анонимной и поможет тем, кто ищет работу в ИТ.

оценить работодателя

ссылка на оригинал статьи https://habr.com/ru/company/habr_career/blog/544326/

Расплатиться за кофе в биткоинах картой Mastercard — да или нет?

Утренний кофе, такси на работу, новые джинсы и все это купить за криптовалюту.
Возможно?

Конечно! — сказал СЕО Mastercard Радж Дамодаран и добавил, что у каждого должна быть возможность расплатиться криптой за любой товар в 2021 году.

Каким бы ни было ваше отношение к криптовалюте — от воодушевленного фанатика до ужасного скептика — факт остается фактом — эти цифровые активы становятся неотъемлемой и все более важной частью огромного мира платежей.

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

Почему Mastercard такие переборчивые?

Невозможно усидеть на двух стульях: быть одновременно децентрализованным и зарегулированным и поддержать все криптовалюты. Попробуем представить союз Bitcoin и Mastercard.

«Mastercard» — международная платежная система, которой принадлежит 26% платежных карт во всем мире. В случае мошенничества или потери карты, Mastercard может принять решение об отмене перевода в одностороннем порядке даже через несколько недель. Активный борец с отмыванием денег, терроризмом и знающий каждого своего клиента «в лицо».

«Bitcoin» — первая криптовалюта, которая была разработана, чтобы подорвать власть правительств и обычных финансовых институтов. Не секрет, что биткоин использовался для гемблинга, даркнета, террористами, наркоторговцами и прочими субъектами, не желающими себя показывать. Эти же аргументы применимы и к другим ведущим криптовалютам — Ether, Litecoin и Dogecoin.

Поэтому выбор Mastercard пока пал на стейблкоины, которые более регулируемы и надежны, чем в недавнем прошлом. А чтобы остальные могли подружиться с Mastercard, нужно соответствовать основным критериям:

  • Защита потребителя, включая конфиденциальность и безопасность информации о потребителях. То есть тот же уровень безопасности, который люди ожидают от своих кредитных карт
  • Протоколы строгого соответствия, в том числе KYC «Знай своего клиента» — требование, направленное на пресечение незаконной деятельности и обмана в платежных сетях
  • Цифровые активы должны соответствовать местным законам и постановлениям в регионах, в которых они используются
  • Криптоактивы должны обеспечивать стабильность, необходимую людям для трат, а не инвестиций

Следовательно, в 2021 может и можно будет расплатиться картой Mastercard в криптовалюте, но купить кофе за Биткионы в ближайшем будущем нам не светит. Ведь слова «стабильность», «протоколы соответствия» и «защита», вероятно еще не скоро можно будет поставить рядом со словом Bitcoin.

ссылка на оригинал статьи https://habr.com/ru/company/icon_partners/blog/544236/

Как катать релизы несколько раз в день и спать спокойно. Доклад Яндекса

Высокие темпы разработки сопряжены с рисками, влияющими на отказоустойчивость и стабильность — особенно если хочется экспериментировать и пробовать разное. Разработчик Маркета Мария Кузнецова рассказала о релизном цикле своей команды от и до, а также о мониторингах и других вещах, позволяющих обновлять сервис со скоростью три релиза в день.

— Всем привет! Я представляю бэкенд-разработку курьерской платформы. Поговорить хочу о том, как нам удается, с одной стороны, двигаться быстро, а, с другой стороны, не потонуть в ворохе и потоке проблем и ошибок.

(…) Сейчас у нас в среднем выкатывается по три релиза в день.

Стек технологий, которые мы используем типичен для Java-приложений Маркета. Мы используем 11-ю Java, Spring, PostgreSQL для хранения данных, Liquibase для накатывания миграций и Quartz для регулярных Cron-задач. Конечно, у нас реализовано много интеграций с внутренними сервисами.

Начать я хочу с того, как у нас устроен процесс релиза.

1. Релизы

С самого начала проекта мы живем в парадигме trunk-based development. Чтобы код попал в продакшен, нужно поставить пул-реквест и пройти код-ревью. Причем в пул-реквесте запускаются также и прикоммитные проверки, в первую очередь это юнит-тесты и функциональные тесты.

Среды у нас сейчас только две — продакшен и тестинг. Когда код-ревью пройдено и код попал в trunk, запускается вот такой релизный пайплайн.

Дальше я покажу все шаги подробнее.

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

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

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

Конечно, у нас есть ограничения при выкатке релиза. Парадигма trunk-based development диктует то, что не должно быть долго живущих feature branches, и получается так, что в trunk может оказаться незаконченная функциональность.

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

При чем здесь кот Шредингера? Часто новая функциональность в продакшене должна и работать, и не работать одновременно: для каких-то пользователей должна быть включена, а для других все должно работать по-старому. Можно было бы, конечно, поднять отдельный инстанс, бэкенд с новой функциональностью, пустить туда какую-то часть пользователей, а остальных оставить на старых.

Но такой подход звучит дорого.

2. Feature toggles

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

if (configurationService.isBooleanEnabled(NEW_FEATURE_ENABLED)) {     //new feature here } else {         //old logic }

Можно выкатить код и пока не использовать его в продашкене, например, ждать поддержки фронтенда или же дальше его реализовывать.

Нам очень важно уметь включать-выключать функциональность по отмашке от коллег. Поэтому свой toggles мы сложили в базу.

public class User {     private Map<String, UserProperty> properties = new HashMap<>();      String getPropertyValue(String key) {         UserPropertyEntity userProperty = properties.get(key);         return userProperty == null ? null : userProperty.getValue();     } }

Поскольку функциональность не всегда нужно сразу включать на всех пользователей, сделали feature toggles на пользователя и тоже положили их в базу. Так мы можем точечно включать функциональность, и это дает возможность провести эксперименты. Например, мы делали новую функциональность под кодовым названием «Звонки». Это напоминание курьеру о том, что у него скоро доставка. (…) Такая функциональность сильно перестраивала процесс работы курьера, и нам было важно проверить, как процесс летит в реальном времени, в реальной жизни.

По первым результатам эксперимента мы поняли, что после звонка курьеру некуда записать комментарии от пользователя. Поэтому срочно добавили комментарии и возможность работы с ними. И дальше уже пользователей в эксперимент добавляли только с этой функциональностью. С помощью feature toggles у нас сделана выкатка на процент пользователей. Мы храним версию и требуем от курьера, чтобы у него была установлена именно она. В противном случае просим его обновиться.

Конечно, у такого подхода есть минусы. Toggles скапливаются, и здесь ничего не остается, кроме как их убирать. Также увеличивается сложность тестов, потому что проверять свой код нужно во всех режимах работы toggles. Кроме того, toggles лежат в базе, поэтому получается лишний поход в БД. Здесь ничего не остается, кроме как поставить кэш. Какие плюсы мы за это получаем?

Мы получаем возможность спокойно жить в парадигме trunk based development. Также можем проводить точечные эксперименты на пользователях.

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

Мобильное приложение обычно тоже раскатывается не сразу на всех пользователей, а вначале на какой-то процент из них. И мы можем получить такую ситуацию, что в зависимости от пользователя бэкенд должен иметь разную логику. Это не только изменения в API, но и именно изменения в бизнес-логике. Toggles нам тоже помогают решить такую задачу.

Остался вопрос про деградацию. Мы обслуживаем офлайн-процесс, и в случае любых проблем с ПО нам нужно сделать так, чтобы самая важная часть функциональности работала. Чтобы курьеры могли выдать посылку, выбить чек и понять, куда ехать дальше.

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

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

3. Метрики и мониторинги

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

Какую информацию мы собираем? На слайд я выписала формальное определение метрик и мониторинга.

Но предлагаю рассмотреть, что это такое, на примере.

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

Какие могут быть действия? Конечно, самое важное — уведомить ответственных: написать в мессенджер или позвонить. Реже — запустить процесс откатки последнего релиза. У себя в проекте мы такой вариант не используем. Еще есть вариант мониторинга, который мы называем «загорается лампочка». Произошло интересующее нас событие, и оно отобразилось в интерфейсе мониторинга. Дальше тоже происходит действие — уведомить ответственных или еще что-то.

Мы говорим про Java-приложение, а оно должно быть где-то запущено, будь то контейнеры или железные машины. Ресурсы и в том, и в другом случае для нас конечны, нам нужно понимать, как мы их используем. Наши приложения мы запускаем во внутреннем облаке, облако нам предоставляет всю подобную информацию. Информацию о ресурсах стоит собирать не только на контейнерах, где живет ваше приложение, но и там, где работает ваше хранилище.

На слайде пример, как нам в базе перестало хватать CPU.

Окей, у нас Java-приложение, и, конечно, стоит собирать информацию о состоянии JVM.

Мы используем Spring, поэтому для решения такой задачи хорошо подходит библиотека Spring Boot Actuator. Она добавляет endpoint в ваше приложение, и к этому endpoint можно обратиться по http и получить необходимую информацию о памяти или что-то еще. Окей, приложение запущено. Дальше оно вообще работает или нет? Что с ним происходит? Можно отправлять запросы в это приложение или нет?

@RestController @RequiredArgsConstructor public class MonitoringController {     private final ComplexMonitoring generalMonitoring;     private final ComplexMonitoring pingMonitoring;      @RequestMapping(value = "/ping")     public String ping() {         return pingMonitoring.getResult();     }      @RequestMapping(value = "/monitoring")     public String monitoring() {         return generalMonitoring.getResult();     } }

Такие вещи нужно понимать не только нам, но и балансеру. Для этого мы добавляем в приложение контроллер с двумя методами — Ping и Monitoring. Рассмотрим вначале Ping. Он отвечает на вопросы, живо ли приложение, можно ли отправлять на него запросы. И отвечает он это в первую очередь не нам, но балансеру. Но мы же используем этот метод для мониторинга того, живо приложение или нет.

Метод Monitoring дает нам возможность получать сообщения о неполадках в системе. Например, не удалось загрузить знания, с которыми работает приложение, или не удалось их обновить. Или же процесс по распределению заказов между курьерами закончился ошибкой.

public enum MonitoringStatus {     OK,     WARNING,     CRITICAL; } @RequiredArgsConstructor public class MonitoringEvent {     private final String name;     private volatile long validTill;     private volatile MonitoringStatus status; }

Мониторинги строятся на системе статусов и приоритетов между ними. Событие мониторинга в минимальном варианте описывается именем, временем, до которого действует мониторинг, но и статусом. По истечении этого времени мониторинг считается пройденным, погашенным и переходит в статус «ok».

public interface ComplexMonitoring {     void addTemporary(String name, MonitoringStatus status, long validTillMilis);     Result getResult(); //тут можно делать проверку для статусов в MonitoringEvent } 

Получается такой простейший интерфейс мониторинга. Добавить или обновить событие и вернуть текущее состояние мониторинга в оговоренном формате.

У нас есть клиент — мобильное приложение, нужно понимать, как качественно мы отвечаем клиенту и какая вообще нагрузка на нас идет. Поэтому стоит собирать RPS, тайминги и пятисотки.

Как мерить RPS, понятно из названия. Стоит отметить, что хорошо смотреть как общий RPS по приложению, так и по отдельным методам API. А вот с двумя остальными — с таймингами и пятисотками — все не так понятно. В каждый момент времени может быть много запросов и, соответственно, много времен ответов. Всю эту информацию нужно агрегировать. Для этого хорошо подходят перцентили. Этот термин пришел к нам из статистики.

Чтобы рассказать, что это такое, на слайде есть нижний график, на нем выделена точка в 400 мс. Это график 99 перцентиля какого-то метода из нашего API. Что значат эти 400 мс? Что в этот момент 99% запросов отрабатывали не хуже 400 мс.

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

Как мы собираем RPS, тайминги и пятисотки? Когда запрос оказался у нас в инфраструктуру, он попадает на L7 balancer. А дальше он не сразу попадает в приложение, перед этим есть nginx.

А вот уже из nginx он попадает в приложение. У nginx есть access.log, в который можно собирать всю необходимую информацию. Это коды ответа, время ответа и сам запрос.

Часто, когда возникают проблемы с временем ответа или пятисотки, стоит посмотреть, что в это время было с хранилищем.

У нас PostgreSQL, поэтому мы именно его мониторим и смотрим. Мы строим все эти графики не сами — они нам предоставляются облаком, в котором развернута наша база. Что у нас есть? Количество запросов, транзакций, лаг репликации, среднее время транзакции и так далее. На самом деле на этих графиках представлен факап, который у нас произошел.

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

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

public class MetricQueryRealJobExecutor {     private static final RowMapper<Metric> METRIC_ROW_MAPPER = BeanPropertyRowMapper.newInstance(Metric.class);     private final JdbcTemplate jdbcTemplate;      public void doJob(MetricQuery task) {         List<Metric> metrics = jdbcTemplate.query(task.getQuery(), METRIC_ROW_MAPPER);         metrics.forEach(metric -> KEY_VALUE_LOG.info(KeyValueLogFormat.format(metric))         );     }      @Data     private static class Metric {         private String key;         private double value;     } } 

Но далеко не всегда на такие мониторинги должна реагировать разработка. Очень часто на них вначале нужна реакция бизнеса. Вообще задача получения статистики по хранилищу выходит однотипной. Нужно сходить в базу, рассчитать статистику, а результат записать в key-value-лог. Поэтому мы сделали обертку для таких задач.

Сложили в базу такую тройку: уникальный ключ для метрики, сам запрос, в котором можно эту метрику посчитать, и Cron-выражение, когда считать. То есть в базе получилась тройка: ключ — запрос — cron expression. А над всей этой тройкой сделали Cron-задачу, которая достает ее из хранилища и добавляет к общему пулу Cron-задач. Дальше эта задача выполняется.

Итого, что мы получаем?

  • Плохой код не должен попадать в продакшен, для этого мы ставим всевозможные преграды: тесты, стрельбы, мониторинги. Задача без тестов не считается сделанной. Лучше заниматься оптимизацией работы тестов, чем получить проблему в продакшене.
  • Feature toggles помогают нам управлять логикой работы бэкенда, а мы, в свою очередь, можем легко управлять toggles, и их плюсы все-таки перевешивают минусы.
  • Мы должны уметь быстро обнаруживать проблему, в идеале — раньше, чем ее заметят наши пользователи. Но ее мало обнаружить, нужно еще ее интерпретировать. Поэтому собирайте много метрик о состоянии системы. Это помогает в поиске проблемы.

И, конечно, давайте будем писать код без багов, тогда у нас вообще все будет хорошо. На этом у меня все.

ссылка на оригинал статьи https://habr.com/ru/company/yandex/blog/542842/