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

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

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

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

В вашем примере использовался 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 'Изменения отправлены в репозиторий'

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

❯ Прозрение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Всё ещё ищете толкового ассистента? Наймите нейросеть! Разбор возможностей нейропомощников

• Код-послание из сериала «Черное зеркало: Захват голубя» расшифрован отечественным клоном ZX Spectrum 1992 года

• Teensy 4: Arduino на скорости 600 МГц (почувствуй себя властелином вселенной)

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

Wordpress конечно хороший, бесплатный движок, но хотелось попробовать что-то новое.

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

Установка Ghost CMS

В целом движок можно установить двумя способами.

Через подписку на официальном сайте

Можно попробовать установить "приведение" купив подписку на официальном сайте.

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

Установка Ghost CMS на свой сервер

💡Сразу нужно сказать, что сервер нужен не начального уровня. Несмотря на то, что на официальном сайте рекомендуют сервер на базе Ubuntu с 1 гб оперативной памяти, лучше арендовать сервак с большим объемом.

Да можно установить и запустить и вроде будет работать, но при работающем серваке у меня постоянно было 950-960 мб занятой оперативки. Это приводило к ошибкам 502 и 504.

Поэтому мой минимум это 2 гб оперативной памяти, сервер с Ubuntu 22.04 и 20 гб физической памяти.

💡Еще одно уточнение. Лучше устанавливать Ghost CMS на чистый дистрибутив.

Я имею ввиду, если у вас уже есть арендованный сервак с настроенным Nginx, Apache либо другим конфигом, то с большой вероятностью будут конфликты либо ошибки.

У меня есть арендованный сервер, там 1 проект на Wordpress и сервер Ubuntu, на котором установлена Fastpanel. Я попробовал установить Ghost CMS, но получал ошибку "Message: Could not communicate with Ghost". Ушел гуглить, но поиск дал несколько ответов, про Nodejs. Он должен быть рекомендованной версии, но я следовал инструкции на оффсайте и поэтому это не помогло.

Затем я решил попросить помощи у хостера. Открыл тикет и после пары часов ковыряний технической поддержки - получил ответ.

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

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

Также статья на Хабре, подтверждает, что установить Ghost CMS с панелью ispmanager - реально.

Кто не шарит за английский, отличный перевод с комментариями сделал Дмитрий Яковлев в его статье "Как установить Ghost на VPS".

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

Для избежания этой ошибки вводим в терминал следующую команду:

sudo apt install cron

Далее проблем с установкой быть не должно.

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

Ошибка ERR_TOO_MANY_REDIRECTS

Для работы с доменами я использую Cloudflare. На этом домене раньше был сайт на другом движке. Настройки в клауде я оставил прежние.

При установке движка Ghost CMS я получал ошибку ERR_TOO_MANY_REDIRECTS.

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

После поисков решений проблемы, было установлено, что всему виной настройка SSL/TLS encryption.

💡Важно! После установки Ghost CMS encryption mode: нужно установить в режим Full (Strict).

Именно так. Любые другие настройки будут приводить к ошибкам.

Подводя итоги

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

Продолжаю изучать Ghost CMS, думаю будет еще немало ошибок. Но знакомство с этим движком мне напоминает знкомство с Ubuntu, когда на начальном этапе была просто куча ошибок и много времени занимал поиск на их устранение. Теперь один из дистрибутивов Linux, а именно Void - моя домашняя система. Что-то мне подсказывает, что с Ghost CMS будет похожая история...