Сообщество - Лига Сисадминов

Лига Сисадминов

2 191 пост 18 705 подписчиков

Популярные теги в сообществе:

96

Пять эмоциональных состояний программиста

Пять эмоциональных состояний программиста
21

Краткое пособие по програмно-определяемым системам хранения данных

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

Windows Storage Spaces Direct

Единица отказа: отдельный сервер, и, при настройке stretched cluster – отдельный сайт (локация).
Плюсы: Есть огромное руководство по настройке. Публичный опыт эксплуатации.
Выжал 13.7 миллионов IOPS (на чтение) еще в 2018 году, семь лет назад - см. The new HCI industry record: 13.7 million IOPS with Windows Server 2019 – на 12 x 2U Intel® S2600WFT
Позволяет одновременно работать виртуальным машинам на том же хосте - для того и сделан.
Минусы: нормально работает на не всяком железе (список тут).
Стоит сотни нефти из-за лицензирования.
Для настройки нужно много читать, но читать открытую документацию. Для работы нужна нормальная сеть (25/100/200G, хотя заведется и на 10G). Нет калькулятора IOPS – что понятно, разные диски, разные коммутаторы. Кому-то и 460 ns на Brocade G710 в самый раз, кто-то берет нормальный, быстрый Ethernet с его ~50 ns на 7130E.
Особенно хорошо у любителей импортозамещения заходят Brocade и Cisco MDS одновременно. Так сказать, прямо до сердечка через access gateway бекпорт , хоть до гланд и не достанут*.

Начиная с версии Server 2022, обычно, не взрывается. Но есть нюансы с кешированием, резервированием памяти, конфигурациями, etc.

VMware (by Broadcom) vSAN 8.0.

С названием теперь совсем путаница. Фирмы VMware, после завершения ее покупки Broadcom, больше нет. Broadcom Software Group переименована в VMware. Но в 2023 году сообщали, что Raghu Raghuram больше не CEO. Но на сайте Broadcom он по прежнему CEO. На официальном сайте продукт по прежнему называется VMware vSAN 8.0.
Единица отказа: отдельный сервер, и, при настройке stretched cluster – отдельный сайт (локация).
Плюсы: Есть огромное руководство по настройке. Есть публичный опыт эксплуатации. Выжимает какие-то рекорды, причем заявленные "It can deliver up to 3.6 million IOPS per storage cluster" - это на чем-то среднем, я видел уже и 6 миллионов IOPS на кластере на 8 обычных хостов на чтение блоком 4к.
Позволяет одновременно работать виртуальным машинам на том же хосте - для того и сделан.
Минусы: нормально работает не на всяком железе (список пока открыт). Стоит сотни нефти, еще и по подписке. Для настройки нужно много читать, но читать открытую документацию.  Для работы нужна нормальная сеть (25/100/200G, хотя заведется и на 10G).
Начиная с версии 7u3 обычно не взрывается. Хотя под кривыми руками отлично умирает.

Nutanix

Единица отказа: отдельный сервер, и, при настройке Metro Availability – отдельный сайт (локация).
Плюсы: он даже продавался в РФ.
Позволяет одновременно работать виртуальным машинам на том же хосте - для того и сделан.
Минусы: без поддержки и сейлов будет грустно. Плюс все, перечисленное выше, для S2D и vSAN

Xinnor xiRAID

Единица отказа: отдельный диск. Это только RAID, но есть решение Virtual RAID Appliance (VRA).
Говорят, хороший. Но цены не найти.

Raidix

Единица отказа: отдельный сервер, но через использование Lustre Object Storage Service (OSS)
Говорят, стал гораздо лучше. Даже руководство по использованию есть. Но списка совместимости нет совсем, а в руководстве указано:
Если у вас возникли проблемы с совместимостью, пожалуйста, обратитесь в техническую поддержку

SYNOLOGY – Xpenology

Оно даже как-то будет работать. На нормальном железе даже нормально заработает. Только это не кластеризуемое решение на «простом серверном железе». Хотя SYNOLOGY уже и кластеризуемое, о чем пишут в статье NAS High Availability Using a Synology NAS Appliance & LINBIT Software.

Freenas - TrueNAS сюда же. Или нет. Там даже дедуп завезли.

Ceph

Единица отказа: отдельный сервер
Плюсы: бесплатный. Есть исходный код. И с прямыми (очень прямыми) руками обычно даже работает.
Минусы: железа нужно МНОГО. Для того, чтобы получить ту же производительность, что и в коммерческих решениях выше, нужно в 4 (четыре) раза больше железа. Потому что вы не можете запустить сколько-то значимое количество виртуальных машин на том же хосте, где у вас развернуто хранение. Потому что сервис просто безудержно тратит процессор и память.
Поэтому вам нужно железа x2 – половину на хранение, половину на вычисление. (Такое решение есть и у Broadcom - vSAN Max, где собирается огромные кластер только для хранения).
Еще x2 железа нужно на хранение потому, что оптимизацией бесплатного решения (по скорости и по erasure coding и deduplication) в паблике никто особо не занимался. Хотя возможность и упомянута в документации.
Имеет привычку падать по производительности на ребилде, и много когда еще. Просто так падать, если все работает, перестал (но не всегда, еще несколько лет назад умирал на ребилде). Обновление между версиями теоретически существует, практически историй успеха в паблике еще поискать.
Теоретически, в том же Proxmox заявлено:
For small to medium-sized deployments, it is possible to install a Ceph server for using RADOS Block Devices (RBD) or CephFS directly on your Proxmox VE cluster nodes (see Ceph RADOS Block Devices (RBD)). Recent hardware has a lot of CPU power and RAM, so running storage services and virtual guests on the same node is possible.
Практически - вы, конечно, попробуйте.

LINSTOR

Единица отказа: отдельный сервер
Оно запускается. И даже работает. Но пока никто из запустивших не смог отчитаться, на каком железе, под какой нагрузкой, и сколько это будет стоить. Под капотом DRBD и Pacemaker, со всеми их проблемами, как и LVM и ZFS, а теперь еще и drbd-reactor.
Заявлен рекорд в 25.504.950 IOPS, но.
In 2020, LINBIT® measured 14.8 million IOPS on a 12-node cluster to record the highest storage performance reached by a hyper-converged system on the market.
То есть почти то же самое, что на 12 нодах получил Microsoft в 2018 году. Калькулятор storage TCO calculator – убрали с сайта. Наверное, что-то не то калькулировал. Механизм HA был реализован странновато, через отдельный контроллер.
С учетом того, что с осени 2024, у OpenZFS 2.3.0 заявлен Fast Dedup, и того, что Тестирование на одиноком Kingston DC600M 1.92TB SSD SATA показывает ничего, и существования статьи OpenZFS deduplication is good now and you shouldn't use it – что значит «ну есть и есть, использовать не надо», то применимость решения в чем-то серьезнее ООО Ромашка – под вопросом. У статьи есть русский перевод, но зачем он нужен, если все равно вся остальная документация на английском?

SeaweedFS

Держитесь подальше от этого болота.

Все прочие «свои разработки аналоговнетного класса»

Особенно с формулировкой на всякие сео-помойках «наш SDS может работать на любом commodity-железе».
Это, как легко понять, 70/30 маркетинговое вранье.  Программа, скорее всего, запустится. И даже будет работать, пока не случится что-то с железом.
Память вылетит, диск, памяти не хватит на ребилд (это, скорее, к Ceph), SFP модуль откажет, и начнутся задержки по одному из путей. Возможны любые неприятности, вплоть до того, что кривой "дописанный" драйвер ОС будет чуть криво работать с FW конкретной партии дисков, а выявится это спустя 2 месяца эксплуатации. Или спустя два года без патчей, как у HPE с их ровно 32,768 часов до потери данных (3 года, 270 дней 8 часов).
Годится (за редкими исключениями) только для включения в реестры, и для поставок за тонны нефти тем, кто не смог отказаться.

Дело не том, что оно "совсем не работает". Оно, может, и хорошо работает на 100% исправном железе в коротком - сутки, неделя - тесте, но. Но перевод "на русский линукс" заявлен еще в 2007 году, а в 2025 опять просят субсидий и
дать четкий сигнал государственным и корпоративным потребителям.
Переход у Huawei от OceanStor S5300 / OceanStor S3900 (какой это год, 2010 ?) к Huawei OceanStor V3 (представлена в РФ в 29.04.2015, выпуск начат в 2014) занял примерно пять лет.
Переход от Dorado 2100 (2011) к Dorado 2100 G2 (2012) и OceanStor Dorado5000 V3 (2016) - где-то пять лет. При огромном внутреннем спросе, гос.поддержке и сквозной интеграции в комплексные решения, и при открытых внешних рынках. Есть ли шансы на качество у решений, которые ориентированы только на рынок РФ, даже не РБ? Не знаю. Да мне и не интересно.

Заключение

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

Не имеет смысла обсуждать любые аналоговнеты и опенсорс решения в отрыве от средств производства, требований бизнеса и требований доступности. И готовности платить за доступность.
Если вы нанимаете на работу Васянов, которые скачивают с торрентов сборку ZverPostgre (реальный случай), то вам вообще все равно, что там с данными. Это при наличии в природе Postgres Docker Official Image.
Если у вас за час простоя не произойдет ничего, кроме криков «доколе!», а за потерю дневной работы бухгалтерии придется проставить большой, но торт тем людям, которые будут повторно делать какие-то проводки и учет, то вам не очень нужна система, с надежностью 99.99. Точно так же нет смысла обсуждать все решения с нескучными обоями.

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

Значит, что вместо тестирования писали баг репорты.

Фраза из того же теста того же аналоговнета

Сбои в подсистеме питания вообще никак не повлияли на производительность

Восходит к прекрасной истории. На тестировании другого аналогонета, из него выдернули один блок питания, и это ВООБЩЕ НИКАК СОВСЕМ НИЧУТЬ ВОВСЕ не отразилось на аналоговнете. В смысле, ни алертов, ни событий. Потому что изначальный код писали на железе с одним блоком питания, и алерт «нет питания» просто отсутствовал, за ненужностью. Говорят, исправили. Сколько не исправили?

Но самое интересное начинается, когда нужно обновлять микрокод в самом диске.

* утерянная народная мудрость

Показать полностью
2

Определённая область знания

Определённая область знания
213

"JavaScript — это разводной ключ программирования. Может использоваться для чего угодно, но это лучший инструмент ни для чего"

"JavaScript — это разводной ключ программирования. Может использоваться для чего угодно, но это лучший инструмент ни для чего" Картинка с текстом, Мемы, IT юмор, Backend, Разработчики, Языки программирования, Javascript
Показать полностью 1
11

Техподдержка Microsoft Office 365

Здравствуйте всем! Кто-нибудь знает, есть ли сейчас возможность получить техподдержку микрософта не от индусов на https://support.microsoft.com, а от нормальных наших технарей российских?

В организации пользовались учетками вида user@domain.com для микрософтовских сервисов типа тимс, бесплатными, бизнес-планов нет никаких. недавно админ на https://admin.microsoft.com привязал домен domain.com к своей учетной записи и все поломалось. Теперь ни в сервисы войти ни в админ панель с учетками user@domain.com. Я так понял, создался пустой тенант для этого домена, в котором нет прежних учеток, при попытке входа с учетками user@domain.com просто сообщение, что нет таких учетных записей. Гуглеж показывает, что нужно отменить привязку домена, а это только техподдержка руками может ибо доступа у нас в админку больше нет. Индусы тупят и посылают подальше. Интересно, у нас осталась вменяемая поддержка или нет, у кого какой опыт, куда бежать, кому сдаваться.

1326

Выпившая женщина — себе не хозяйка

Выпившая женщина — себе не хозяйка
12

Ответ на пост «Ansible для Mikrotik: бэкапы по identity и псевдо-иммутабельность»1

Спасибо за статью.

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

Правда, автор путает термин индепотентности и иммутабельности.

В вашем примере использовался SVN. Я делал с GIT.
Не всё делал с ансабль, поэтому присутствует костыль в виде скрипта. Скрипт будет ниже.

По хорошему, вместо скрипта также нужно использовать ansible

#!/bin/bash

name_branch=$(date "+%d.%m.%Y_%H%M")

echo "Имя новой ветки $name_branch"

path_files="/home/user/mikrotik"

backupConfig(){

ansible-playbook $path_files/playbooks/export_config.yaml -i $path_files/hosts/$1 | sed -e '1,10d' | head -n -7 > $path_files/mikrotik/$1

echo "Файл $1 записан"

}

list_ip=$(ls -l $path_files/hosts/ | awk '{print $9}')

for var in $list_ip

do

backupConfig $var

done

git -C $path_files/mikrotik/ branch $name_branch

echo 'Ветка создана'

git -C $path_files/mikrotik/ checkout

git -C $path_files/mikrotik/ add .

echo 'Добавлены файлы в индекс'

git -C $path_files/mikrotik/ commit -m "$name_branch"

echo 'Зафиксированы изменения'

git -C $path_files/mikrotik push --set-upstream origin "$name_branch"

echo 'Изменения отправлены в репозиторий'

Показать полностью

Считаете себя киноманом 80 LVL?

Залетайте проверить память и сообразительность → Будет интересно

74

Человек-клей: как я нашел самого неэффективного сотрудника, чуть не уволил, а оказалось, что на нем все держится

Автор текста: Maslukhin

Человек-клей: как я нашел самого неэффективного сотрудника, чуть не уволил, а оказалось, что на нем все держится IT, Карьера, Менеджмент, Программист, Timeweb, Длиннопост

Эпиграф:
Приходит чувак к музыкантам, в группу просится. Те у него и спрашивают:
А ты на гитаре играть умеешь?
Нет.
А на барабанах?
Тоже не умею.
Может ты поешь?
Не пою.
Зачем ты нам тогда нужен?
Знаете, я просто офигенный друг!

Рано или поздно любой хороший продакт начинает покрывать метриками свою команду. В одной из продуктовых групп так и случилось: продакт ввел метрики, постепенно вычислил самого неэффективного сотрудника — назовем его Петя — и уже готовил бумаги на увольнение. Но во время этого веселого процесса вдруг выяснилось, что общие высокие показатели команды, это заслуга совсем не продакта (опаньки!), а именно «неэффективного» Пети. Потому что Петя оказался «человек-клей». Тот самый парень (или девушка), ради общения с которым собирается команда, который умеет поддержать, вдохновить, снять негатив и вообще настроить команду на продуктивный лад. При этом он вполне может быть распоследним раздолбаем.

❯ Почему это в блоге TimeWeb

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

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

Почему? Был интересен взгляд со стороны менеджмента, который обычно стесняется называть вещи так, как считает на самом деле (а там цинизма — мама не горюй). Было любопытно, что несмотря на некоторые спорные идеи, менеджмент может трезво смотреть и на себя, и на разработчиков и даже признавать собственные ошибки (анонимность воистину творит удивительные вещи :). Плюс, понравился сам стиль изложения и «грабли», на которые любят наступать оптимизаторы и любители метрики. В общем, много причин.

Далее — сама история от лица продакта, перешедшего на эту позицию из разработки. Мы только слегка ее «причесали», вставили подходящие картинки и структурировали.

❯ «Охота на неэффективных»: как менеджеры пытаются измерить неизмеримое

Процесс задания метрик — залипателен. Особенно если начать их разворачивать внутрь команды. В бытность разработчиком я привык покрывать метриками микросервисы для оптимизации — иногда удавалось «выжать» 10-кратный прирост производительности.

Работая уже как продакт, я начал применять метрики для оценки команды разработки. По сути, люди — это такой же набор специализированных микросервисов, каждый со своим характером, скоростью работы и требовательностью к ресурсам. Причем, как и микросервис, их можно «убедить» работать в согласии с другими сервисами (главное — подобрать правильный API), ускорить или и вовсе заменить на более производительный. Да, довольно цинично, но это позволяет смотреть на разработку трезвым взглядом. Плюс, моя команда показывала хорошие результаты. Это значило, что мой метод работал (забегая вперёд — ха-ха).

Человек-клей: как я нашел самого неэффективного сотрудника, чуть не уволил, а оказалось, что на нем все держится IT, Карьера, Менеджмент, Программист, Timeweb, Длиннопост

Крутой продакт входит в чат

Естественно, я не рассматривал безумные метрики типа:

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

Любая из таких метрик легко забивается имитацией деятельности, не приближая к конечному результату. Поэтому мои метрики были прагматичнее: продолжительность логина в системе, количество завершенных Story Points, процент завершенных задач относительно взятых на спринте, время первой реакции на тикеты/код-ревью. Плюс я отслеживал количество сообщений на одного человека в корп. чате и — моя гордость — количество подходов к кофемашинке с последующим сравнением времени возвращения к работе.

Человек-клей: как я нашел самого неэффективного сотрудника, чуть не уволил, а оказалось, что на нем все держится IT, Карьера, Менеджмент, Программист, Timeweb, Длиннопост

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

Собственно, на последних метриках у меня и попался Петя. Я-то искренне гордился высокой командной Velocity по количеству Story Points и низкой долей незакрытых задач из спринта. Вот что значит, хорошая организация процесса, нахваливал я себя. Но стоило перейти к анализу персональных метрик — как картина переставала быть ровной и у меня выявлялось несколько аутсайдеров и, да-да, наш Петя. Прямо-таки статистическим вылетом.

Во-первых, он закрывал наименьшее количество задач. Во-вторых, лидировал по количеству заказов кофе и времени по логину после кофе-паузы. Среднее время «кофе-паузы» у него составляло 37 минут. Плюс, он мог просто сорваться на кофе за компанию. На тикеты и на результаты код-ревью он реагировал с огромным запозданием, зато строчил очень много сообщений в командной ветке чата. Вообще, складывалось впечатление, что наш Петр приходит в офис бесплатно поесть, выпить кофе, провести пару TЕD-выступлений у кофемашины, хорошенько после поболтать и, где-то между этими делами, немного поработать.

Человек-клей: как я нашел самого неэффективного сотрудника, чуть не уволил, а оказалось, что на нем все держится IT, Карьера, Менеджмент, Программист, Timeweb, Длиннопост

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

И тут Петя ушел в отпуск, что-то он там в этом отпуске не того съел и слег на больничный на еще +2 недели. И наши метрики поползли вниз. Ну бывает, сезонность. А потом он вышел, в офисе увеличился расход печенек и метрики опять поползли вверх.

❯ Прозрение

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

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

Потом этот же Петя дозвонился нашему базисту, напомнил, что они вечером должны играть в нашей группе (у нас в комнате отдыха есть уголок с гитарами, барабаном и синтезаторов и иногда ребята что-то там себе «рубят»), и базист согласился приехать. Заодно посидеть с джунами, помочь им запросами на постгресс. И все это с шутками, подколами и какой-то совершенно теплой атмосферой, которой не видно во время регулярных созвонов. Там обычно все собранные и ответственные, а Петя и вовсе старается не отсвечивать, зная свою производительность. А тут все — одновременно и вовлеченные и расслабленные.

❯ Неформальные движки команды (нет, не серые кардиналы)

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

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

Человек-клей: как я нашел самого неэффективного сотрудника, чуть не уволил, а оказалось, что на нем все держится IT, Карьера, Менеджмент, Программист, Timeweb, Длиннопост

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

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

Человек-клей: как я нашел самого неэффективного сотрудника, чуть не уволил, а оказалось, что на нем все держится IT, Карьера, Менеджмент, Программист, Timeweb, Длиннопост

❯ Как выжить в мире бессмысленных метрик

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

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

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

Что я сформулировал для себя по итогам:

  1. Команда ценнее одного сотрудника (да банальность, но очень легко скатиться на личности).

  2. Если команда может «прокормить» одного или нескольких типа лишних сотрудников и эти сотрудники делают эту команду лучше — они не лишние.

  3. Мы же перестали экономить на офисах и печеньках? Почему же тогда не распространяем этот принцип на людей?

  4. Нет, аниматоров и блек-джек в офис звать рано.

  5. Прямые метрики отлично работают с железом и софтом, но не работают с людьми.

  6. Более того, узнав про них, люди обижаются и начинают искать пути обхода. Да просто из принципа.

  7. Если человек справляется со своими задачами и не токсичен для окружающих, то, по идее, чего тебе еще надобно?

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

  9. Хорошие отношения в команде — самое ценное. Более ценное, чем дедлайны. Но без дедлайнов тоже никак.

❯ Вместо заключения

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

А какое ваше мнение? Какие «теневые» лидеры были в ваших командах, ценность которых не выявлялась прямо, но без которых команда бы развалилась? И да, чтобы сделать пост более ценным, хотелось бы еще уточнить у коллективного разума, какие бредовые метрики были у вас и как вы их обходили?


Написано специально для Timeweb Cloud и читателей Пикабу. Больше интересных статей и новостей в нашем блоге на Хабре и телеграм-канале.

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

📚 Читайте также:

Показать полностью 6
Отличная работа, все прочитано!