Роутеры бывают разные

Читатели спрашивают: кто что использует сейчас в качестве роутера, чтобы удовлетворял всем современным требованиям к трубопроводам, КВН и всему такому прочему?

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

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

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

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

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

Это может быть как «малинка» / «бананка» / «репка» или что-то более серьезное на x86. Из нового – это компактные неттопы на N100, которые можно купить от 18 000 - 25 000 руб., из б/у можно посмотреть на Авито неттопы на J1900 / N 3xxx, которые можно купить в хорошем состоянии где-то за 8000-10 000 руб.

А если у меня есть NAS / Медиасервер / Домашняя лаба (нужное подчеркнуть)? Нет и еще раз нет. Сетевые службы являются критически важными и поэтому должны быть доступны 24/7 вне зависимости от других сервисов.

Поэтому отдельная железка – самое то. Сегодня на нее, как минимум, логично возложить функции VPN / Прокси и локального кеширующего DNS.

А что же роутер? А роутеру оставим его основную функцию – маршрутизацию.

Что касается самого роутера, то мы видим тут три основных варианта:

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

🔹 Keenetic – достаточно мощная и продвинутая платформа с низким порогом входа и дружелюбным интерфейсом. Может многое и не требует специфичных знаний для настройки. Минусы – достаточно дорого. Плюсы – хороший Wi-Fi из коробки.

🔹 OpenWRT – привет красноглазие. Порог входа не ниже, чем на Mikrotik, а то еще и побольше. Потому как надо еще уметь прошивать, заливать, разблокировать и прочую аппаратно-программную магию. Но возможности там практически как у нормального Linux и роутер можно взять относительно недорогой. По Wi-Fi – как повезет, но скорее да, чем нет.

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

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

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

Отдельный хост – как сосредоточие сетевых служб: VPN, Proxy, DNS и все что может понадобиться еще. Там стоит классический Linux и возможности ограничены только вашей фантазией и наличием пакетов.

Узкий профиль или болото?

В комментариях время от времени всплывает вопрос эксплуатации откровенно старых систем. Мол все что вы пишете – хорошо, но попробуйте это применить на … (можете вписать любой устаревший софт).

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

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

Далее от его лица, моя только литературная обработка.

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

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

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

Стек технологий у меня оставался стабильным, точнее стабильно древним: FoxPro, Visual Basic 6, Windows, COM и 1С на обычных формах. Новая 1С, которая 8.3 и на управляемых формах как-то не зашла (там сильно переучиваться надо было) и стояла только в бухгалтерии, благо дорабатывать ее было не нужно.

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

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

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

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

Также посмотрел я и на «новую» 1С, которая оказалось может и умеет гораздо большее, чем я мог себе представить.

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

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

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

Но что делать как-то в голову не приходило. Да, надо было учить, но когда?

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

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

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

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

Интернет по паспорту

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

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

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

Первыми тревогу забили крупные рекламные сети, а за ними контентные площадки и авторы контента. Причина проста – такие боты накручивают просмотры, искажают поведенческие факторы, скликивают рекламу.

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

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

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

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

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

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

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

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

Сегодня для этого уже есть специальный термин Proof of Personhood (доказательство человечности) и ведутся первые такие разработки, скажем World ID от Сэма Альтмана, также рассматриваются аппаратные ключи и телеметрия без деанонимизации.

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

Кризис доверия. Часть 1: как нейросети ломают общественный договор открытого веба

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

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

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

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

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

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

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

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

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

Фактически это будет реализация теории «Мёртвого интернета» (Dead Internet Theory), т.е. сети, в которой генерируют и потребляют контент боты, они же комментируют и голосуют и делать живому человеку в таком вебе нечего.

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

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

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

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

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

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

Проблема медленного клиента в Wi-Fi сетях

Многие читатели высказывают скептическое отношение к современным стандартам Wi-Fi, мол все это ни к чему, когда есть старый-добрый 802.11n, да и 2,4 ГГц добивает дальше. Но не все так просто и в этой заметке постараемся коротко рассказать об этом.

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

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

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

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

Для примера возьмем квадрат определенного размера и разметим его сеткой 2х2 – получим 4 ячейки, если же возьмем сетку 4х4 – то ячеек уже будет 16, а при размере сетки 8х8 целых 64. Исходный квадрат у нас будет обозначать доступную полосу, а сетка – модуляцию.

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

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

Все стандарты до 802.11n (Wi-Fi 4) включительно предусматривают работу по принципу «один говорит – остальные молчат», т.е. точка одновременно работает только с одним клиентом.

Начиная со стандарта 802.11ac (Wi-Fi 5) предусмотрен режим многопользовательского MIMO, когда точка может передавать данные одновременно сразу нескольким клиентам (но не наоборот).

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

В 802.11ax (Wi-Fi 6) добавили исходящие потоки и теперь точка может не только передавать, но и принимать данные от нескольких клиентов одновременно.

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

Начнем с устаревших, эта проблема наиболее характерна для диапазона 2,4 ГГц, даже если точка поддерживает все современные стандарты, например, как в новых Mikrotik 802.11b/g/n/ax (Wi-Fi 6), то в такой сети у нас всегда найдутся устройства 802.11n.

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

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

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

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

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

Поэтому самым разумным способом на сегодняшний день является использование двух диапазонов: 5 ГГц и 2,4 ГГц.

В первом будут собраны преимущественно современные устройства и работать будут как минимум на уровне 802.11ac, а все старые устройства сбросим на 2,4 ГГц на 802.11n.

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

Кризис доверия. Часть 2: Proof of Personhood и Machine Authority

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

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

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

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

А вот с самим подтверждением не все так просто, сегодня наиболее активно продвигаются следующие методы:

🔹 WEI / Attestation – система аппаратного контроля, где источником доверия является TPM. Браузер запрашивает у аттестатора специальный криптографический токен, подтверждающий, что клиентская среда не модифицирована, используется «правильный браузер» и т.д.

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

🔹 World ID (Tools for Humanity) – предусматривает сканирование радужки глаза, которая является уникальной, при помощи специального Orb-сканера, на основе снимка вычисляется хеш и добавляется в специальную базу, сам снимок после этого удаляется.

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

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

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

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

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

Недостаток очевиден – строгая привязка ко времени. Если ты пропустил время теста – твой уровень доверия в системе падает.

☝️ Хорошо, с пользователями разобрались, а как быть с легальными ботами? Например, поисковых сетей? Для них также предусмотрена аналогичная система - Machine Authority, которая аналогичным способом будет подтверждать, что данный бот является доверенным.

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

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

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

Личный бренд

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

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

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

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

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

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

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

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

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

Следующий важный вопрос – это ваша целевая аудитория. Для кого вы ведете свой блог или канал? Для таких же как вы специалистов? Так откуда там появятся заказчики или работодатели? Ну вот откуда?

Что приводит читателя на ваш ресурс? Его приводят туда материалы, прочитав которые он может сделать все сам и бесплатно. Ему не нужен исполнитель и он не ищет сотрудников.

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

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

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

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

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

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

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

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

Как быть? Грамотно расставить приоритеты. Желаете заниматься публицистикой – занимайтесь, но четко представляя, что никаких реальных бустов в профессиональной деятельности она вам не даст. Это не реальный профессиональный опыт.

Кризис доверия. Часть 3: уйти не получится или зачем это нужно обычному пользователю

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

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

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

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

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

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

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

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

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

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

Это моментально убьет 80-90% небольших авторских проектов и небольших команд, у которых просто перестанет сходиться бюджет.

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

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

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

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

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

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

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

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

Залить железом

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

Начнем с самого способа – он прост, как мычание. Его смысл – если вам не хватает аппаратных ресурсов, то просто пойдите и купите их.

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

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

Почему? Потому что дает бизнесу четкие суммы и сроки. Если у вас есть мониторинг (а он же есть?), то нет никакого труда выявить тренды и сделать прогнозы, тем более что с такими задачами прекрасно справляется ИИ. После чего вы говорите: нужно купить то и это, сумма такая, на год-полтора вопрос закроем.

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

А вот тропа оптимизации куда более скользкая. Там нет ответа сколько это будет стоить и что мы в итоге получим. Потому что для начала надо оплатить аудит и анализ. Стоит это будет XXXX руб./час, оплатить надо минимум NN часов.

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

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

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

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

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

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

Ладно, оставим аутсорс, возьмем нужного специалиста в штат. А сколько будет стоит этот специалист? Явно не дешево, так что это та же самая ежемесячная «дань», только несколько в ином виде.

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

Но вы не подумайте, мы вовсе не против оптимизаций. Но подходить к этому вопросу нужно трезво и взвешенно.

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

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

Почему не следует использовать ретрансляторы Wi-Fi

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

Ну а что, просто, дешево и сердито. Воткнул в розетку и Wi-Fi снова появился. При этом мало кто задумывается над неочевидными подводными камнями данного решения.

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

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

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

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

Но что произойдет, когда у нас появится повторитель? С точки зрения беспроводной сети повторитель – это еще один клиент, причем для обеспечения стабильного покрытия его следует размещать в пределах уверенного приема от точки доступа (50% перекрытия).

К чему это приводит? Как мы помним Wi-Fi работает по принципу – один говорит, остальные молчат. А повторитель у нас говорит два раза, как клиент основной точки и как точка для своего клиента. Т.е. занимает дополнительные слоты передачи.

Т.е. вместо одного устройства у нас как-бы появляется два. Вместо двух – четыре и т.д.

При этом сами устройства, подключенные через повторитель, потеряют где-то 50% полосы, так как одни и те же данные потребуется передавать в одном радиоканале два раза: от клиента к повторителю и от повторителя к точке (и точно также в обратном направлении).

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

Простой и очень грубый пример: 4 устройства поделят между собой беспроводную полосу примерно поровну – по 25% на каждого.

Теперь берем 2 устройства напрямую и два через репитер. В результате полоса поделится уже на 6 устройств (два за репитером удваивают используемую полосу).

И опять-таки в идеальных условиях мы уже получим не 25, а 16% полосы на устройство.

До поры до времени, особенно если беспроводные устройства представлены нетребовательными клиентами и общей полосы хватает с запасом – это не заметно.

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

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

Почему абонентская плата — это плохое решение?

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

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

Как обычно выглядит типовой договор на абонентное обслуживание? Это короткая бумага, где написано примерно следующее:

Исполнитель осуществляет абонентное технико-информационное обслуживание, включающее в себя: обслуживание программного обеспечения, принадлежащего Заказчику и услуги по обслуживанию компьютерной и оргтехники…

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

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

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

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

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

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

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

Как быть? Работать по факту? А если фактов не будет? Тоже писали, что за два года по факту заплатили как за два месяца обслуживания.

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

Первое и самое востребованное – консультации. Звонить будут всегда. Вводим тариф: N часов консультаций – NNN рублей. Тарификация по 15 минут. Превышение – MMM руб./час, ну или купить еще один пакет.

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

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

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

Если были срабатывания триггеров, то тоже отражаем в отчете эти факты и принятые нами меры.

Продаем профилактику – даем отчет по профилактике.

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

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

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

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

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

Узкий профиль или болото? Часть 2.

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

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

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

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

Обмен происходил штатными средствами 1С через РИБ, т.е. с задержкой в 15-20 минут. Но перед этим данные еще должны были попасть в 1С из нашей внутренней программы, которая взаимодействовала с 1С через COM и там тоже была задержка в 5-10 минут, в зависимости от объемов данных.

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

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

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

А кладовщик: как накладная придет – так отгружу, извини, я материально ответственное лицо.

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

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

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

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

К виртуализации у меня долгое время было отношение как к чему-то не для простых смертных. Ну да, работая в основном на Server 2003 / 2008 было немудрено.

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

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

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

Но посмотрев на виртуалки и контейнеры в деле я стал понемногу внедрять виртуализацию у себя по принципу «один сервис – одна виртуалка». Процесс тоже был довольно непрост. Зато теперь можно гибко управлять всей инфраструктурой не боясь, что обновление сервиса А завалит сервисы Б, В, Г, Д и далее по алфавиту.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Узкий профиль или болото? Заключение.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это любители ставить в продакшен Gentoo, FreeBSD, Solaris и тому подобную экзотику, прекрасно понимая, что в обозримом пространстве специалистов по этой системе не найти и они вроде как на коне.

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

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

Вот сейчас поиск на HH по слову Linux показывает в Москве 7303 вакансии, по слову FreeBSD – всего 44. И это при том, что коммерческая разработка у нас нацелена на DEB/RPM и нестандартная ОС автоматически означает отсутствие официальной поддержки.

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

Бег в колесе, как спрыгнуть?

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

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

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

А для этого достаточно сесть и подумать: а что я буду делать через 10 лет? Или куда я пойду, если моя контора завтра закроется?

Также рекомендуется внимательно изучить вакансии на том же HH и примерить их на себя. Если не примеряется – следовательно вы выпали с рынка и надо что-то делать.

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

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

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

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

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

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

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

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

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

Что? Клиенты откажутся? Да и пес с ними. Потому как приехать, посмотреть регистратор, потом кабанчиком метнуться в магазин за новым диском, поменять, все пояснить-разъяснить и потратить три часа за тысячу-полторы заодно выслушивая недовольство заказчика – это явно игра с отрицательным результатом.

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

Надо срочно? Срочность оплачивается отдельно. Хочешь поорать? Дома на жену поори. Приехать? Дорога оплачивается. Поехать купить? Так тоже не бесплатно. Не нравится – привози железо сам и оплачивай доставку из магазина.

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

Большой опрос

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

Заодно посидел, подумал и сделал некоторые выводы, для себя, на будущее.

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

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

Большой SLC-кеш, хорошо ли это?

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

Те редкие модели с памятью MLC которые сегодня можно встретить в продаже относятся к устаревшим моделям с интерфейсом SATA и их скоростные характеристики оставляют желать лучшего.

Сама TLC память достаточно медленная, и чтобы улучшить скоростные характеристики накопителя был придуман SLC-кеш.

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

Таким образом максимальный объем SLC кеша для TLC не может превышать 33,3% емкости накопителя, а для QLC – 25%.

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

Один из распространенных алгоритмов кеширования предусматривает выделение под кеш большого объема, примерно в 30% от свободного объема накопителя.

Что это значит? Это значит, что мы перевели в SLC-режим практически всю память, потому что 30% кеша – это 90% объема.

Да, такой кеш будет поддерживать высокую скорость записи, но по его исчерпанию диску просто становится некуда писать. Поэтому ему приходится одновременно уплотнять запись, переводя SLC-ячейки в TLC-режим и принимать новые данные. При этом скорость записи катастрофически падает, местами до 100 МБ/с и ниже.

Другая стратегия предлагает выделение небольшого объема под кеш 5-10% емкости диска. При этом основная часть ячеек диска остается в режиме TLC и по исчерпании кеша вполне способны обеспечить скорость записи в районе весьма комфортных 400 – 500 МБ/с.

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

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

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

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