Специалист ну очень широкого профиля

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

И каждый раз выяснялось, что занимаются коллеги классическим «пойди туда – не знаю куда, принеси то – не знаю что». Процитирую:

…потом выясняю, что им какой то 3Д вьювер нужен, который на встроенной графике не работает, начали смотреть требования…, я говорю ща порешаем, привожу на следующий день свой 710 Жефорс, запускаем на нем, прога летает …, я нахожу в ДНС им 710, присылаю им счет, она его оплачивают, но им в ломак ехать забирать, я опять еду к клиенту беру доверенность, в ней в ДНС…

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

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

А коллеги терпят и бегают как дрессированная собачка боясь потерять эту самую сумму денег.

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

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

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

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

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

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

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

Как мы уже говорили – это бизнес. И проблемы вашего контрагента – это проблемы вашего контрагента, которые не следует перекладывать с больной головы на здоровую. Нет, переложить можно, но с соответствующей оплатой.

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

Купить ПК и поставить ОС – ОК, вот вам ПК с системой, с вас денежка. Спасибо, держите работайте.

Что, проблемы с каким-то приложением? Ну так, а мы тут причем, тем более что вы нас не предупреждали. Можем посмотреть, готовьте столько-то денег. Вот видеокарта нужна. Дорого? Ну так не мы эти цены ставим.

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

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

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

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

Не спеши, а то успеешь

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

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

Любые нормы на чем-то да основаны, проверены временем и т.д. и т.п. Сказали чистить снег пару – значит пару. Это сегодня снега пару сантиметров выпало, и вы за полчаса справились, а завтра его по колено наметет? А норма – штука такая, если ее регулярно перевыполнять, то ее обязательно поднимут (или сократят) и легче никому от этого не станет.

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

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

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

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

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

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

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

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

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

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

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

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

Для себя я давно вывел некоторые эмпирические коэффициенты, любые материалы на проекте умножаем на 1,25, а время просто увеличиваем в полтора, а то и два раза. Запас карман не тянет, особенно если это такой ресурс, как время.

И снова спрашивали про ценообразование, и снова отвечаем.

Про почасовку

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

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

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

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

Или вы написали скрипт, который все делает за вас. Тут тоже заказчик может задать вопрос – а за какие часы я плачу? Если ты только два раза по файлу кликнул, а потом сидел смотрел в экран?

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

А если выставили время, то будьте добры его отработать. Или сократить свои хотелки согласно реально отработанного времени.

Мы не раз и не два сталкивались с конфликтами, когда внедренец по ТЗ выставлял, скажем, 200-250 часов, закрывал их силами одного специалиста за месяц, а после чего заказчик отказывался оплачивать счет и настойчиво интересовался, каким образом это физически стало возможно. Может специалист там на цепи сидит?

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

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

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

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

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

А дальше уже не важно сколько времени вы потратили на ее реализацию. Обещали неделю, а справились за три дня – молодцы, сразу видно настоящих профессионалов! А цена? Какой была – такой осталась. Заказчик платит за результат.

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

Договаривались на что? На результат. Вот результат. Вот деньги. Все просто, понятно, прозрачно. И заказчик еще на берегу понимает за что платит. Цена устраивает? Значит работаем.

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

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

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

Databasus - графический инструмент бекапа СУБД

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

Databasus, ранее известный как Postgresus – это именно такой класс инструментов, которые создают графическую обертку для привычных утилит. В данном случае для резервного копирования PostgreSQL, MySQL/MariaDB и MongoDB.

Поставляется все это добро безальтернативно в Docker, для установки вам потребуется создать docker-compose.yml со следующим содержимым:

services:
databasus:
container_name: databasus
image: databasus/databasus:latest
ports:
- "4005:4005"
volumes:
- ./databasus-data:/databasus-data
restart: unless-stopped

Потом стандартное:

docker compose up -d

Обратите внимание, что директория ./databasus-data будет использоваться для локального хранилища бекапов, сразу укажите путь к нужному месту.

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

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

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

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

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

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

Использовать Databasus или нет – каждый решает сам. Ничего особенного в нем нет, это просто добротно сделанная панель закрывающая базовые потребности по резервному копированию СУБД.

✅ Сайт проекта: https://databasus.com/

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

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

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

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

А теперь немного простой арифметики. Допустим ваша цель – 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 минут после устойчивого появления энергоснабжения.

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