Проблема мелкого прайса

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

И это действительно так, если вы и дальше собрались делать все подряд за мелкий прайс, то так и продолжите постоянно этим заниматься без перспектив и просветов.

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

А теперь немного простой арифметики. Допустим ваша цель – 100 000 руб. в месяц. В месяце 30 дней, из них в среднем 21 день рабочий.

Таким образом вам нужно зарабатывать порядка 4 700 руб. в день, что за мелкий прайс означает, что вам нужно успеть окучить не одного клиента. Фактически вы будете бегать как собака с утра до ночи положив язык на плечо.

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

Ну и ваша ценность в глазах заказчика будет на уровне «мальчика, который делает все подряд». Т.е. уровень разнорабочего на стройке. А вот вы, делая ремонт кого позовете класть плитку? Плиточника с отзывами, но дорого, или разнорабочего, но за мелкий прайс?

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

Летом я много времени проводил в райцентре на 14 000 человек по причине внезапно нарисовавшегося объекта недвижимости по типу «домик в деревне». Мог проживать там неделями, работая удаленно, при этом легко и непринужденно нашел себе еще пару клиентов.

Просто разговаривая с предпринимателями в местных магазинчиках. И они были очень рады что ими займется кто-то из «городских». А почему? А потому что местные все «занимаются всем подряд», ну какие из них специалисты.

Только и этих местных еще найти надо, особенно вечером или в выходной день. А та же розница именно вечером основную кассу делает и если вы просто способны отвечать часов до 22, то вам цены не будет.

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

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

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

А также есть более крупные и серьезные клиенты, которых вы на данном этапе просто не видите, потому что они не нуждаются в услугах «разнорабочего от IT».

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

Получается заколдованный круг. Как из него вырваться? Только единственным образом – прекращать работу за мелкий прайс.

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

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

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

Про помогаторов

В продолжение нашего новогоднего цикла «за жизнь» рассмотрим еще один феномен – как помогаторство.

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

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

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

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

А попытка таки вернуть ситуацию на стартовую позицию с покупкой адекватного железа обернется тем «а почему ты мне сразу не сказал» и вряд ли вы снова что-то нормально заработаете. Плюс вам заказчик будет постоянно внушать чувство вины за ваш прошлый «прокол».

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

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

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

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

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

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

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

Здесь все гораздо проще. Доступно объясняете заказчику, на понятном ему языке, что может произойти и какие варианты вы предлагаете на этот случай. Отказывается – объясняем еще раз. Предельно понятно. Вот это сервер, он сгорел, нафиг, совсем, ничего нет. Что делать будешь?

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

И здесь мы плавно подходим к тому, что нужно уметь твердо, но корректно говорить заказчику нет, когда он пытается попутно нагрузить вас другой проблемой. Следует пояснить, что выполнили вы один объем работ, то, что он хочет – это другое, это другой объем услуг и другая оплата.

Хороший пример был в комментариях, мол вы настроили нам обмен, а теперь у нас не идут остатки. Тут все просто, обмен – это обмен. Работает? Ну прекрасно, вот акт, вот счет.

Надо что-то решать с остатками? Это другая услуга, стоить будет примерно столько. Устраивает? Работаем.

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

Прекращена поддержка HP-UX

31 декабря без лишнего шума и пыли компания Hewlett Packard Enterprise прекратила поддержку своей операционной системы HP-UX, оставив расширенную поддержку до 2028 года только для серверов на базе Intel Itanium.

Таким образом ушел в историю еще один мастодонт мира настоящего, проприетарного UNIX. История системы уходит корнями в 1984 год, когда Hewlett Packard потребовалась система для своей архитектуры PA-RISC (HP 9000).

За основу была взята популярная коммерческая System III, а позже, начиная со второй версии более современная System V. Это была классическая UNIX-система, хотя никакого единства в те годы в рядах UNIX не было и близко.

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

Если мы посмотрим вокруг, то на рынке в те времена существовали коммерческие AIX, SunOS (позже Solaris), Xenix (позже SCO UNIX), IRIX и другие игроки. Тут же, недалеко в сторонке, стояло семейство BSD с открытым исходным кодом.

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

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

А на рынке серверов все было просто: покупаете HP – получаете HP-UX, покупаете IBM – получаете AIX, Sun – SunOS, позже Solaris. И никакой вариативности. Приобретался закрытый программно-аппаратный комплекс.

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

HP-UX вышла по своему интересной, в ней первой из коммерческих UNIX-систем была представлены списки контроля доступа (ACL) и диспетчер логических томов (аналог LVM).

Не обошлось и без курьезов, первая файловая система была основана на UFS и называлась HFS (High-performance File Syste) что совпадало с файловой системой MacOS от Apple. Это вызывало много путаницы и смущало администраторов.

Следующее поколение файловой системы было основано на VxFS компании Veritas Software и было названо JFS (Journaled File System), что снова внесло путаницу, так как файловая система с таким названием уже существовала у IBM.

В начале нулевых Hewlett-Packard совместно с Intel взялась за проект Itanium, линейка серверов от HP на базе этой архитектуры HPE Integrity также поставлялся с HP-UX.

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

Теперь заказчикам не требовалось покупать дорогую проприетарную систему, можно было купить стандартный x86-64 сервер и поставить туда Linux или BSD.

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

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

Как продебажить сеть в контейнере если в нём не хватает утилит?

Иногда слышу вопросы от коллег типа: "Как выполнить какой-нибудь запрос из контейнера, если в нём нет curl?". Или: "Как снять дамп из контейнера, если в нём нет tcpdump?".

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

1. Находим PID процесса контейнера. Обычно для этого достаточно выполнить ps aux | grep "команда запуска вашего контейнера", но если контейнеров запущенной одной и той же командой на хосте много, то лучше воспользоваться CLI вашего рантайма (типа crictl) для опредленя PID'а нужного контейнера.

2. Заходим в сетевой неймспейс этого процесса через команду nsenter -n -t $PID, где -n значит network.

Всё. Можете проверить, что вы там, где нужно, введя команду ip a.

Это очень полезный метод, когда вам либо самим нужно что-то проверить, либо когда нужно доказательство клиенту, что с трафиком из контейнера 100% всё порядке.

Между инцидентами

Реклама. Давыдов И.А. ИНН 775108336633. erid: 2W5zFGaTMax

Где мое бесплатное пиво?

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

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

Свободное ПО – это прежде всего философия, которая предусматривает наличие у пользователя ряда свобод: свободу использования, свободу изучения, свободу изменения и свободу распространения.

Если лицензия ПО обеспечивает указанные свободы, то такое ПО считается свободным, а занимается всем этим Фонд свободного программного обеспечения (Free Software Foundation), именно он принимает решение какие именно лицензии считать свободными. Самая известная свободная лицензия – GPL.

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

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

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

И вот тут возникает первое большое непонимание. Компоненты дистрибутива могут распространяться под разными открытыми и свободными лицензиями. Но сам дистрибутив представляет собой отдельный объект авторского права и его автор может установить собственные правила его использования.

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

Но как же GPL или другие свободные лицензии? А никак, к дистрибутиву они не применимы, они действуют для его компонентов. Вам никто не запрещает свободно их использовать самих по себе, но если вы хотите запускать именно дистрибутив – то будьте добры следовать его лицензии.

Если вам что-то не нравится – исходные коды предоставлены, собирайте сами и используйте по собственному усмотрению. Тут никаких вопросов нет, но бинарные файлы дистрибутива и репозиториев никто не обязывает предоставлять свободно и бесплатно. Здесь автор в праве поставить свои условия.

Поэтому не следует путать отдельные программы со своими лицензиями и их совокупность – дистрибутив. Он является отдельным объектом авторского права и может иметь собственные условия использования. Единственный момент – они не должны нарушать лицензии используемых компонентов.

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

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

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

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

Ну или берете исходные коды и собираете свой.

Открытые системы

В нашей заметке о HP-UX мы говорили о проприетарных коммерческих системах и о том, что они не выдержали конкуренции с открытой архитектурой. Но открытая – это не значит свободная и тем более бесплатная.

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

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

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

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

И вот в начале 80-х на рынке появилось то, что на момент своего появления не имело, с точки зрения гигантов рынка, настоящего, не говоря уже о будущем. И это был IBM PC.

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

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

Впоследствии IBM сильно пожалеет об этом решении, но это будет потом. Первый IBM PC был представлен публике в 1981 году, и компания ставила план реализовать 250 тыс. таких машин в течении 5 лет, но скоро стала продавать такое же количество ПК ежемесячно.

Вместе с этим IBM получила огромное количество клонов, так как никто не мешал другим производителям купить процессор от Intel, систему от Microsoft и выпустить на рынок полностью совместимый ПК.

Со временем рынок отказался от термина IBM PC ,и платформа сначала стала просто PC, а затем x86 и, позже, x86-64.

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

Второй звоночек прозвенел в середине 90-х с выходом Windows NT 3.5, а затем и Windows NT 4.0 Terminal Server, который позволил закрыть потребности в серверных функциях для малого бизнеса без существенных вложений в инфраструктуру.

Теперь сервером мог быть обычный ПК, пусть немного более мощный и дорогой – но самый обычный, все что требовалось – купить серверную ОС от Microsoft или Novell, либо поставить бесплатные BSD или Linux.

Тут еще и Intel подсуетился, выпустив в конце 90-х серверную платформу на базе Xeon.

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

Теперь даже средние и крупные игроки рынка предпочитали не связывать себе руки дорогими проприетарными системами, а купить обычный x86-64 и поставить туда обычный Linux или BSD. Тогда же началось активное развитие коммерческих Linux-систем, того же RHEL, которую в конце концов приобретет IBM.

С тех пор начался быстрый закат проприетарных закрытых систем в пользу открытых архитектур, который мы видим до сих пор. На рынке оборудования между собой конкурируют открытые x86-64 и ARM, появился перспективный открытый игрок RISC-V.

На рынке ОС значимое место занимает открытая платформа Linux и открытые стандарты на многие форматы файлов и алгоритмы обработки.

Что касается периферии, то также канули в лету нестандартные разъемы и протоколы, практически везде для подключения используется USB, а устройство определяется как стандартно

​​Где смотреть «логи» в Windows

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

Отсюда и пошло расхожее мнение, что с журналированием в Windows не очень, не то, что в Linux, где бери нужный лог и читай.

Однако стоит спуститься в оснастке чуть ниже и раскрыть дерево Журналы приложений и служб, как сразу станет ясно, что это не так.

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

И именно этой частью журнала мы пользовались, чтобы разобраться с проблемами Samba в статье: https://interface31.ru/tech_it/2023/05/ispravlyaem-oshibku-podklyucheniya-windows-k-obshhim-resursam-na-servere-samba-linux.html

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

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

🤔 А вы пользуетесь расширенными возможностями оснастки Просмотр событий?

Слишком много изменений…

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

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

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

Если у вас сеть, то эти обновления еще надо разогнать по сети. В общем – дел хватает. И все это, как обычно, надо было еще позавчера.

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

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

В общем, даже если вы героически победите все эти проблемы, то никакой благодарности не заслужите, потому что все будут уверенны, что это IT уронил прод всеми этими обновлениями.

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

Что бывает, когда мы накатываем сразу несколько изменений и получаем после этого проблемы? А бывает то, что мы не знаем, какое именно изменение эти проблемы вызвало и вынуждены отрабатывать массу вариантов. А предприятие все это время работает через пень-колоду.

Кто будет крайним? А тот, кто это все затеял и затеял именно в такой форме.

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

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

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

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

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

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

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

Распределенные системы или история одного блекаута

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

И на все возражения, что это ненадежно обычно есть ответ – ой, да у нас тут интернет хороший, второй канал есть, бесперебойники, стабилизаторы, ну что тут может пойти не так?

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

Бизнес – это про зарабатывать деньги и больше не про что иное. Это может быть не очень приятно осознавать, но именно бизнес платит нам зарплату. Не будет денег у бизнеса – не будет денег у нас.

Простой – это плохо, особенно если у вас скоропортящийся товар и убыток тут складывается вполне реальный, в настоящих рублях, а не в некоторой «упущенной прибыли». А еще хуже, когда у вас простой, а конкуренты худо-бедно, но работают.

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

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

Худо-бедно электроснабжение и связь стали появляться только во второй половине дня, а нормализовалась ситуация только к ночи.

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

И тем, кто сделал ставку на облака или удаленку было вчера плохо, очень плохо. И если облака еще худо-бедно поднимались по мере появления интернета, то с удаленными серверами, расположенными в пределах города, была вообще беда.
Те же, кто использовал распределенные системы, несмотря на более сложную поддержку и обслуживание таковых, пережили блекаут более-менее нормально. Запустили генератор и уже как-то торгуем, пусть даже только за наличные.

Стала появляться связь? Можем начать принимать карты. Появилась связь с офисом – хорошо, нет – и так проживем.

Также сильно помогла децентрализация вспомогательных служб: сервера удаленного администрирования, синхронизации, VPN и т.д. Причем не обязательно использовать для этого публичные сервисы, достаточно купить VPS, это не дорого, но в разы повышает надежность, нежели если бы это все было сосредоточено в центральном офисе.

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

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

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

Также были сделаны правильные выводы насчет ИБП – это не средство резервного питания. Это защита от кратковременных перебоев в энергоснабжении. В случае аварии все что вам нужно – это корректно выключить оборудование.

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

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

Токсичность – наша национальная черта? Привычка?

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

Есть у меня одна родственница, которая в свободное от основной работы время занимается 3D дизайном, преимущественно в Blender. Делает всякий рекламный креатив, чем серьезно поддерживает семейный бюджет.

И вот случилась у нее беда. Сгорел SSD в ноутбуке. Большинство она восстановила, что-то было продублировано, но осталась одна мелочь – 3D-объект воздушных шариков, он был простой, бесплатный, скачанный с сайта с бесплатными объектами.

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

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

Самым первым делом ей объяснили, что она дура. Ну это классика жанра, пропускаем мимо ушей. Дальше ей пояснили, что такое нарисовать самому – пять минут делов, а после посыпались услуги сделать тоже самое от 10 до 25 тыс. руб.

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

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

Перевела свой вопрос переводчиком, извинилась за плохой английский и уже через полчаса получила первое сообщение.

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

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

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

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

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

Тот форум она больше не посещает. Смысла нет. Равно как нет смысла читать его. Практического толка там ноль, зато срач и флуд бьют фонтаном.

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

Хотя я могу привести пример современных комьюнити, лишенных этого недостатка. Иногда можно даже сравнить, скажем в мире 1С есть Инфостарт и Миста. И если первый является вполне современным и дружелюбным, но последняя как деревенский клуб ближе к полуночи.

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

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

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

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

Мониторинг - он такой разный

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

📉 Начнем с совсем простых инструментов. Таких как Системный монитор в Windows или, например, nmon в Linux.

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

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

🟢 Вторая категория - это локальный мониторинг отдельного узла, мы рассматривали одну из таких программ - Monitorix. Она уже постоянно запущена, как сервис и собирает заданные метрики на постоянной основе, а также умеет вовремя оповещать о происходящих событиях.

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

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

🛰 Отдельной строчкой стоят средства мониторинга сети, один из популярных - The Dude от Mikrotik.

Можно ли при помощи Dude контролировать метрики узла? Кое что можно, но для этого есть другие инструменты, более для этого предназначенные. А так и саморезы можно молотком забивать, при великой и неотложной нужде.

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

🏆 Ну и наконец такие монстры уровня предприятия как Zabbix. Многие представляют его как пульт управления ядерным реактором. Где мигают лампочки, рисуются графики, постоянно меняются показатели.

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

Zabbix, как и любой хороший мониторинг такого класса, вообще не должен привлекать к себе излишнего внимания. Его задача вовремя оповестить от том, что где-то там возникла проблема и с этим он отлично справляется.

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

У опытных админов на панели Zabbix обычно всего два виджета: проблемы и история проблем.

☝️ При этом нельзя сказать, что какая-то одна из систем может закрыть на 100% все запросы. Системы мониторинга дополняют друг друга и нет ничего плохого в том, чтобы их комбинировать.