Закон Парето (принцип Парето, принцип 80/20) — «20 % усилий дают 80 % результата, а остальные 80 % усилий — лишь 20 % результата».
Wikipedia

Приветствую тебя, дорогой читатель!

Моя первая статья на Хабр посвящена простому и, надеюсь, полезному решению, сделавшим для меня сбор метрик в Prometheus с разнородных серверов удобным. Я затрону некоторые подробности, в которые многие могли не погружаться, эксплуатируя Prometheus, и поделюсь своим подходом по организации в нём легковесного service discovery.

Для этого понадобится: Prometheus, HashiCorp Consul, systemd, немного кода на Bash и осознание происходящего.

Если интересно узнать, как все это связано и как оно работает, добро пожаловать под кат.

Это часть 1 из серии 2 частей практического руководства по HashiCorp Consul. Эта часть в первую очередь ориентирована на понимание проблем, которые решает Consul и как он их решает. Вторая часть больше ориентирована на практическое применение Consul в реальном примере и будет опубликована на следующей неделе. Давайте начнем.

Любимым вопросом о любой распределенной системе от нетехнического специалиста является “Сколько tps в вашем блокчейне?”. Однако, названное в ответ число обычно имеет мало общего с тем, что хотел бы услышать вопрошающий. На деле, он хотел спросить “подойдет ли ваш блокчейн под мои бизнес требования”, и эти требования — это не одно число, а множество условий — здесь и отказоустойчивость сети, и требования к финальности, размеры, характер транзакций и множество других параметров. Так что ответ на вопрос “сколько tps” вряд ли будет простым, и почти никогда не будет полным. Распределенная система с десятками и сотнями узлов, выполняющих довольно сложные вычисления, может находиться в огромном количестве различных состояний, связанных с состоянием сети, содержимым блокчейна, техническими сбоями, экономическими проблемами, атаками на сеть и множеством других причин. Этапы, на которых возможны проблемы с производительностью отличаются от традиционных сервисов, а сервер блокчейн-сети — это сетевой сервис, сочетающий в себе функционал базы данных, web-сервера и torrent-клиента, что делает его крайне сложным в плане профиля нагрузки на все подсистемы: процессор, память, сеть, storage

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

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

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

Кирилл Розов @kirich1409, известный многим Android-разработчикам, на нашей конференции Mobius выступал с докладом «Как пройти архитектурную секцию собеседования». А заодно на той же конференции ответил Анне Жарковой @anioutka на более общие вопросы о собеседованиях в целом, не связанные с мобильной разработкой.

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

Привет, Хабр! Сегодня у меня для вас отличные новости. В последние несколько лет мы во «Фланте» внимательно следили за технологиями‑лидерами в cloud‑native. Но это вовсе не праздное любопытство: из них мы собрали кое‑что интересное и теперь готовы представить его вам. Речь о новой системе виртуализации, которая появилась в сегодняшнем релизе Deckhouse v1.43.

Готовиться к собеседованию можно по-разному: смотреть ролики на YouTube, читать документацию, положиться на судьбу и тд. В большинстве случаев кандидатам предложат решить одну или несколько задач. В этой статье вас ждет подробный разбор реальной задачки, рекомендации к ее решению и объяснение ожиданий интервьюера от кандидатов.

За последние несколько лет я значительно изменил свой подход к проведению технических собеседований. Если когда-то (лет 7 назад) я мог весело и задорно интервьюировать джавистов два часа, то на текущей позиции у меня нет столько времени на каждого кандидата. При наличии 4 открытых позиций и с результативностью 10% (примерно 10% кандидатов проходят собеседование и готовы принять оффер), получается, что мне нужно провести порядка 40 собеседований. Если тратить хотя бы по часу на собеседование, то это дополнительные 40 рабочих часов, которые где-то надо найти. Плюс накинуть 10 минут на переключение между задачами, получается ещё 400 минут (~6.5 часов).

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

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

Всем привет! Перед началом статьи сразу скажу:

САМЫЙ ВАЖНЫЙ ДИСКЛЕЙМЕР: естественно, покупая смс на чужой номер вы полностью компрометируете безопасность своего аккаунта. Мало ли кто его потом еще купит для получения доступа. Поэтому, помните, что представленный в данной статье способ получения доступа - это только на "поиграться". Не стоит вводить туда свои реальные почты и использовать это в работе, так как полученный доступ может быть в любой момент взломан/прикрыт.

Но да ладно, приступим. Здесь без всякого объяснения того что такое ChatGPT - кому надо тот знает. В этой статье я хочу поделиться путем который вас за 30Р может к этому боту привести. Вдаваться в детали бота я не хочу, это чисто статья для ребят которые хотят без лишних запар пройти путь человека который доступ к боту уже получил :)

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

Программные брокеры сообщения уже стали стандартом при построении больших и сложных систем. Однако до сих пор не все ИТ-специалисты понимают, как работают эти инструменты. Главный системный аналитик «Иннотех» Павел Малыгин помогает разобраться в брокерах сообщениях и их работе.

Всем привет!

Меня зовут Коля, и я периодически собеседую кандидатов на позицию системного аналитика. За последние два месяца провёл порядка 20 десятков собеседований. В основном были кандидаты с опытом 1.5-3 года, на пути к уровню Middle и с зарплатными ожиданиями 150-200 тысяч рублей в месяц.

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

Привет, Хабр! Меня зовут Елена, я ведущий аналитик ИТ-компании SimbirSoft. Сегодня хочу затронуть такую тему, как нефункциональные требования к ИТ-продукту, которым не всегда уделяется должное внимание, а зря. Их несоблюдение может привести к потере прибыли, клиентов, репутации, остановке производственных процессов и большим штрафам, хотя с первого взгляда их влияние на осуществление пользовательского функционала неочевидно. 

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

- мощности и производительности

- безопасности, соответствию стандартам и законодательству

- переносимости и совместимости.

Требования к качеству, несмотря на свой небольшой размер, очень сильно влияют на реализуемость всей совокупности требований, на трудоёмкость, длительность и стоимость реализации, а следовательно окупаемость инвестиций в разработку и в целом возможную успешность проекта.

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

Но в мире честных, открытых отношений выгоднее заранее обсудить эти аспекты, чем потом с удивлением спорить при сдаче, что система тормозит, в ТЗ про это ничего не сказано, «вы же профессионалы» и всё такое.

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

При этом остаётся прагматический вопрос — а что именно писать в требования, чтобы они были полезными, измеримыми, реализуемыми?

С точки зрения системной инженерии, требования к качеству программной системы являются разновидностью системных ограничений (constraints) и в этом они отличаются от требований к способностям (capabilities) системы, в мире ИТ обычно называемых «функциональными».

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

Давайте попробуем сделать это хотя бы ремеслом.

Сейчас менторство считается одним из мощнейших рычагов роста в IT и отличным способом развития soft & hard skills. На рынке уже тысячи менторов по различным тематикам. Но где найти этого эксперта, который подскажет верный путь, поможет решить рабочую задачу, составить план развития или прокачать новый навык?

Доброго времени суток, друзья. Меня зовут Константин Архипов, руководитель проектов в команде DocFlow МТС Digital, преподаватель IT-центра МАИ, амбассадор конкурса «Цифровой прорыв» АНО «Россия – страна возможностей». В этой статье я расскажу о том, как научить специалистов доходчиво рассказывать о своих навыках и сделать из неразговорчивого инженера общительного спикера.

Интересно? Тогда добро пожаловать под кат!

Мы – команда (не первая и не последняя) стартапа CetraPay.