Кризис доверия. Часть 3: уйти не получится или зачем это нужно обычному пользователю
Отзывы на предыдущие части цикла показали, что многие читатели подвержены опасным заблуждениям, мол все это нужно рекламным сетям и владельцам сайтов, продающих рекламу, а обычного пользователя никак не касается. Поэтому посидим, посмотрим, а если начнут навязываться – уйдем туда, где этого нет.
Но проголосовать ногами можно было в старом вебе, когда было много альтернатив и они были достаточно качественными. В новом вебе идти будет просто некуда.
Сегодня, когда ИИ-бота невозможно отличить от человека и их разработка практически ничего не стоит, любая площадка с генерируемым пользователями контентом, наподобие Хабра или Stack Overflow моментально будет забита сгенерированным контентом.
Соцсети заполонят виртуальные аккаунты, ИИ-боты будут спорить в комментариях, отвечать на форумах, оставлять отзывы, давать советы.
Поисковая выдача также будет моментально забита тем же нейрослопом, так как производительность нейросетей на порядок выше человека, и они могут писать качественный с точки зрения SEO текст.
Онлайн сервисы и услуги моментально будут перехвачены ботами, хотите купить билеты, записаться к врачу, купить товар? Вы опоздали, все это уже сделали боты, добро пожаловать к перекупам.
Но то, что вы переплатите, это мелочи жизни, вы просто не сможете качественно выбрать товар, услугу или специалиста, потому что сеть будет заполнена фейковыми отзывами.
Также сразу забудьте про опросы, голосования, конкурсы – все будет накручено и искажено ботами.
При этом напомним, что это не детерминированные боты старой формации, которые вычислялись антифродом по паттернам поведения, а боты новые, умные, которые смотрят на сайт как человек и принимают решения на лету, не используя шаблоны.
Другая идея – сделайте контент по подписке, тоже не выдерживает никакой критики. Обычный человек имеет ограниченное число подписок, не более десятка, обычно 3-5. Музыка, фильмы, какие-то профессиональные медиа, книги, рабочие инструменты. Платить чтобы прочитать рецепт пирога или инструкцию по настройке роутера никто не будет.
Это моментально убьет 80-90% небольших авторских проектов и небольших команд, у которых просто перестанет сходиться бюджет.
Останутся только крупные медиакопорации, что крайне негативно скажется как на качестве, так и на доступности контента. По сути веб, как открытая гипертекстовая система прекратит свое существование.
При этом платная подписка не способна остановить ИИ-ботов, заплатить пару долларов чтобы быстро выкачать весь контент и пустить его на дообучение модели или генерацию собственного контента – это совсем не проблема.
Фактически мы возвращаемся к концепции «мертвого интернета», который перестает быть теорией и становится страшной практикой. В сети, где стоимость генерации контента при помощи ИИ стремится к нулю, а производительность нейросетей на порядки превосходит человека живые авторы и пользователи окажутся в абсолютном меньшинстве.
Доверие перестанет существовать как понятие. Вы не знаете кто написал эту статью или инструкцию, кто оставил отзыв или дает вам совет, с кем вы общаетесь в городском или районном чате. Не знаете реальный ли это человек или очередной ИИ-бот.
Поиск, вместо поиска нужной информации и ответов на вопросы превратится в сито для цифрового мусора.
Поэтому доказательство человечности это то, что нужно именно пользователю, чтобы понимать, что он общается или читает контент других таких же пользователей, а не ботов.
А схема со слепыми токенами позволяет один раз пройти проверку на доверенном ресурсе, а дальше проходить аутентификацию автоматически, не разгадывая на каждой странице капчи с велосипедами или светофорами.
И это не попытка корпораций пересчитать всех по головам и продать рекламу, а вынужденная мера, позволяющая открытому вебу людей выжить в хаосе ИИ окружения.
Отзывы на предыдущие части цикла показали, что многие читатели подвержены опасным заблуждениям, мол все это нужно рекламным сетям и владельцам сайтов, продающих рекламу, а обычного пользователя никак не касается. Поэтому посидим, посмотрим, а если начнут навязываться – уйдем туда, где этого нет.
Но проголосовать ногами можно было в старом вебе, когда было много альтернатив и они были достаточно качественными. В новом вебе идти будет просто некуда.
Сегодня, когда ИИ-бота невозможно отличить от человека и их разработка практически ничего не стоит, любая площадка с генерируемым пользователями контентом, наподобие Хабра или Stack Overflow моментально будет забита сгенерированным контентом.
Соцсети заполонят виртуальные аккаунты, ИИ-боты будут спорить в комментариях, отвечать на форумах, оставлять отзывы, давать советы.
Поисковая выдача также будет моментально забита тем же нейрослопом, так как производительность нейросетей на порядок выше человека, и они могут писать качественный с точки зрения SEO текст.
Онлайн сервисы и услуги моментально будут перехвачены ботами, хотите купить билеты, записаться к врачу, купить товар? Вы опоздали, все это уже сделали боты, добро пожаловать к перекупам.
Но то, что вы переплатите, это мелочи жизни, вы просто не сможете качественно выбрать товар, услугу или специалиста, потому что сеть будет заполнена фейковыми отзывами.
Также сразу забудьте про опросы, голосования, конкурсы – все будет накручено и искажено ботами.
При этом напомним, что это не детерминированные боты старой формации, которые вычислялись антифродом по паттернам поведения, а боты новые, умные, которые смотрят на сайт как человек и принимают решения на лету, не используя шаблоны.
Другая идея – сделайте контент по подписке, тоже не выдерживает никакой критики. Обычный человек имеет ограниченное число подписок, не более десятка, обычно 3-5. Музыка, фильмы, какие-то профессиональные медиа, книги, рабочие инструменты. Платить чтобы прочитать рецепт пирога или инструкцию по настройке роутера никто не будет.
Это моментально убьет 80-90% небольших авторских проектов и небольших команд, у которых просто перестанет сходиться бюджет.
Останутся только крупные медиакопорации, что крайне негативно скажется как на качестве, так и на доступности контента. По сути веб, как открытая гипертекстовая система прекратит свое существование.
При этом платная подписка не способна остановить ИИ-ботов, заплатить пару долларов чтобы быстро выкачать весь контент и пустить его на дообучение модели или генерацию собственного контента – это совсем не проблема.
Фактически мы возвращаемся к концепции «мертвого интернета», который перестает быть теорией и становится страшной практикой. В сети, где стоимость генерации контента при помощи ИИ стремится к нулю, а производительность нейросетей на порядки превосходит человека живые авторы и пользователи окажутся в абсолютном меньшинстве.
Доверие перестанет существовать как понятие. Вы не знаете кто написал эту статью или инструкцию, кто оставил отзыв или дает вам совет, с кем вы общаетесь в городском или районном чате. Не знаете реальный ли это человек или очередной ИИ-бот.
Поиск, вместо поиска нужной информации и ответов на вопросы превратится в сито для цифрового мусора.
Поэтому доказательство человечности это то, что нужно именно пользователю, чтобы понимать, что он общается или читает контент других таких же пользователей, а не ботов.
А схема со слепыми токенами позволяет один раз пройти проверку на доверенном ресурсе, а дальше проходить аутентификацию автоматически, не разгадывая на каждой странице капчи с велосипедами или светофорами.
И это не попытка корпораций пересчитать всех по головам и продать рекламу, а вынужденная мера, позволяющая открытому вебу людей выжить в хаосе ИИ окружения.
👍22👎6❤3💯1
Залить железом
В обсуждениях в очередной раз столкнулись с одним из способов решения проблем с нехваткой ресурсов в информационных системах, который среди коллег называется «залить железом». Многие негативно к нему относятся, но совершенно зря.
Начнем с самого способа – он прост, как мычание. Его смысл – если вам не хватает аппаратных ресурсов, то просто пойдите и купите их.
Нет, мы не будет рассматривать явно пограничные случаи, вроде того, когда администратор вовсе не удосужился выполнить оптимизацию и грамотное выделение ресурсов, а будем исходить из того, что у нас есть нормальная, среднестатистическая система, которой вдруг стало тесно.
Здесь у нас есть два пути – просто пойти и купить недостающий ресурс или стать на путь оптимизации. Но в большинстве случаев первое будет проще, быстрее и, как это ни странно, выгоднее.
Почему? Потому что дает бизнесу четкие суммы и сроки. Если у вас есть мониторинг (а он же есть?), то нет никакого труда выявить тренды и сделать прогнозы, тем более что с такими задачами прекрасно справляется ИИ. После чего вы говорите: нужно купить то и это, сумма такая, на год-полтора вопрос закроем.
Отлично. Если проблема решается деньгами – то это не проблема, а просто статья затрат. Бизнес понимает что именно он сейчас покупает и на какой период эти затраты следует относить.
А вот тропа оптимизации куда более скользкая. Там нет ответа сколько это будет стоить и что мы в итоге получим. Потому что для начала надо оплатить аудит и анализ. Стоит это будет XXXX руб./час, оплатить надо минимум NN часов.
Ну а по факту вы получите просто анализ вашей инфраструктуры и рекомендации. И не факт, что вердикт не будет звучать как: купите новое железо.
Оптимизация, тоже не дешевое удовольствие и хорошо если разовое. Иначе бизнес попадает в зависимость от оптимизаторов и их поддержки. Особенно это касается оптимизации коробочных продуктов с регулярными обновлениями, например, 1С:Предприятие.
Да, вам переписали запросы, оптимизировали цепочки. Но теперь вы при каждом обновлении должны повторять весь этот процесс заново, что резко увеличивает стоимость поддержки такого решения.
А теперь снова посмотрим на это все со стороны бизнеса. В первом случае ему предлагают потратить некоторую сумму денег здесь и сейчас и закрыть проблему на год-полтора. Потом повторить.
Это понятно, это хорошо ложится в бизнес-планирование и дает понимание, когда нужно подкопить резервы и запланировать очередные траты.
Сценарий с оптимизацией обычно выглядит как – у вас проблема, но вы попали на бабки, ежемесячная такса такая-то. И как соскочить с этой иглы решительно непонятно.
Ладно, оставим аутсорс, возьмем нужного специалиста в штат. А сколько будет стоит этот специалист? Явно не дешево, так что это та же самая ежемесячная «дань», только несколько в ином виде.
И снова никто не гарантирует, что через год-полтора старательных оптимизаций вам снова не скажут, что все, ресурсов больше нет, оптимизировать нечего, покупайте новое железо, а там продолжим.
Но вы не подумайте, мы вовсе не против оптимизаций. Но подходить к этому вопросу нужно трезво и взвешенно.
Если проблему можно залить железом – просто залейте. Особенно если это решает проблему на продолжительный временной отрезок.
А оптимизация – это уже когда низы не хотят, а верхи не могут жить по-старому. Т.е. когда проблема уже явно железом не заливается и требует серьезного перестроения всей инфраструктуры. В этом случае да, даже небольшая оптимизация помогает здесь и сейчас, а также дает время и ресурсы для качественных изменений.
В обсуждениях в очередной раз столкнулись с одним из способов решения проблем с нехваткой ресурсов в информационных системах, который среди коллег называется «залить железом». Многие негативно к нему относятся, но совершенно зря.
Начнем с самого способа – он прост, как мычание. Его смысл – если вам не хватает аппаратных ресурсов, то просто пойдите и купите их.
Нет, мы не будет рассматривать явно пограничные случаи, вроде того, когда администратор вовсе не удосужился выполнить оптимизацию и грамотное выделение ресурсов, а будем исходить из того, что у нас есть нормальная, среднестатистическая система, которой вдруг стало тесно.
Здесь у нас есть два пути – просто пойти и купить недостающий ресурс или стать на путь оптимизации. Но в большинстве случаев первое будет проще, быстрее и, как это ни странно, выгоднее.
Почему? Потому что дает бизнесу четкие суммы и сроки. Если у вас есть мониторинг (а он же есть?), то нет никакого труда выявить тренды и сделать прогнозы, тем более что с такими задачами прекрасно справляется ИИ. После чего вы говорите: нужно купить то и это, сумма такая, на год-полтора вопрос закроем.
Отлично. Если проблема решается деньгами – то это не проблема, а просто статья затрат. Бизнес понимает что именно он сейчас покупает и на какой период эти затраты следует относить.
А вот тропа оптимизации куда более скользкая. Там нет ответа сколько это будет стоить и что мы в итоге получим. Потому что для начала надо оплатить аудит и анализ. Стоит это будет XXXX руб./час, оплатить надо минимум NN часов.
Ну а по факту вы получите просто анализ вашей инфраструктуры и рекомендации. И не факт, что вердикт не будет звучать как: купите новое железо.
Оптимизация, тоже не дешевое удовольствие и хорошо если разовое. Иначе бизнес попадает в зависимость от оптимизаторов и их поддержки. Особенно это касается оптимизации коробочных продуктов с регулярными обновлениями, например, 1С:Предприятие.
Да, вам переписали запросы, оптимизировали цепочки. Но теперь вы при каждом обновлении должны повторять весь этот процесс заново, что резко увеличивает стоимость поддержки такого решения.
А теперь снова посмотрим на это все со стороны бизнеса. В первом случае ему предлагают потратить некоторую сумму денег здесь и сейчас и закрыть проблему на год-полтора. Потом повторить.
Это понятно, это хорошо ложится в бизнес-планирование и дает понимание, когда нужно подкопить резервы и запланировать очередные траты.
Сценарий с оптимизацией обычно выглядит как – у вас проблема, но вы попали на бабки, ежемесячная такса такая-то. И как соскочить с этой иглы решительно непонятно.
Ладно, оставим аутсорс, возьмем нужного специалиста в штат. А сколько будет стоит этот специалист? Явно не дешево, так что это та же самая ежемесячная «дань», только несколько в ином виде.
И снова никто не гарантирует, что через год-полтора старательных оптимизаций вам снова не скажут, что все, ресурсов больше нет, оптимизировать нечего, покупайте новое железо, а там продолжим.
Но вы не подумайте, мы вовсе не против оптимизаций. Но подходить к этому вопросу нужно трезво и взвешенно.
Если проблему можно залить железом – просто залейте. Особенно если это решает проблему на продолжительный временной отрезок.
А оптимизация – это уже когда низы не хотят, а верхи не могут жить по-старому. Т.е. когда проблема уже явно железом не заливается и требует серьезного перестроения всей инфраструктуры. В этом случае да, даже небольшая оптимизация помогает здесь и сейчас, а также дает время и ресурсы для качественных изменений.
👍18❤4
Почему не следует использовать ретрансляторы Wi-Fi
Если не хватает покрытия беспроводной сети, то обычный пользователь идет в магазин и покупает там ретранслятор, он же повторитель, и он же усилитель беспроводного сигнала.
Ну а что, просто, дешево и сердито. Воткнул в розетку и Wi-Fi снова появился. При этом мало кто задумывается над неочевидными подводными камнями данного решения.
А подводных камней там хватает. Практически все повторители, а в бюджетном сегменте поголовно все работают на той же частоте что и базовая точка доступа, т.е. занимают один и тот же канал, полоса пропускания которого делится на все беспроводные устройства.
Ширина канала – величина строго ограниченная, как и количество данных, которые мы можем передать за единицу времени. Время доступа к каналу также равномерно делится между всеми подключенными устройствами.
Причем делится оно не по времени, а по количеству переданных пакетов. Т.е. медленный клиент будет занимать больше эфирного времени для передачи одного и того же объема данных.
В идеальном случае, когда все устройства работают с одной и той же скоростью, канал поделится между устройствами примерно равномерно.
Но что произойдет, когда у нас появится повторитель? С точки зрения беспроводной сети повторитель – это еще один клиент, причем для обеспечения стабильного покрытия его следует размещать в пределах уверенного приема от точки доступа (50% перекрытия).
К чему это приводит? Как мы помним Wi-Fi работает по принципу – один говорит, остальные молчат. А повторитель у нас говорит два раза, как клиент основной точки и как точка для своего клиента. Т.е. занимает дополнительные слоты передачи.
Т.е. вместо одного устройства у нас как-бы появляется два. Вместо двух – четыре и т.д.
При этом сами устройства, подключенные через повторитель, потеряют где-то 50% полосы, так как одни и те же данные потребуется передавать в одном радиоканале два раза: от клиента к повторителю и от повторителя к точке (и точно также в обратном направлении).
Но, как мы уже сказали выше, страдать будут не только клиенты репитера, но и клиенты основной точки доступа за счет появления в сети паразитного дублирующегося трафика.
Простой и очень грубый пример: 4 устройства поделят между собой беспроводную полосу примерно поровну – по 25% на каждого.
Теперь берем 2 устройства напрямую и два через репитер. В результате полоса поделится уже на 6 устройств (два за репитером удваивают используемую полосу).
И опять-таки в идеальных условиях мы уже получим не 25, а 16% полосы на устройство.
До поры до времени, особенно если беспроводные устройства представлены нетребовательными клиентами и общей полосы хватает с запасом – это не заметно.
Но если мы начнем подключать к беспроводной сети требовательные устройства, например, телевизоры 2К – 4К, то это очень быстро станет заметно. Особенно если за репитер переместится несколько медленных клиентов, которые начнут отравлять жизнь всем остальным в два раза активнее.
Про цепочки из нескольких повторителей мы и говорить не хотим, фактически это приведет к кратному увеличению дублирующегося трафика и приведет к катастрофическому падению производительности сети.
Если не хватает покрытия беспроводной сети, то обычный пользователь идет в магазин и покупает там ретранслятор, он же повторитель, и он же усилитель беспроводного сигнала.
Ну а что, просто, дешево и сердито. Воткнул в розетку и Wi-Fi снова появился. При этом мало кто задумывается над неочевидными подводными камнями данного решения.
А подводных камней там хватает. Практически все повторители, а в бюджетном сегменте поголовно все работают на той же частоте что и базовая точка доступа, т.е. занимают один и тот же канал, полоса пропускания которого делится на все беспроводные устройства.
Ширина канала – величина строго ограниченная, как и количество данных, которые мы можем передать за единицу времени. Время доступа к каналу также равномерно делится между всеми подключенными устройствами.
Причем делится оно не по времени, а по количеству переданных пакетов. Т.е. медленный клиент будет занимать больше эфирного времени для передачи одного и того же объема данных.
В идеальном случае, когда все устройства работают с одной и той же скоростью, канал поделится между устройствами примерно равномерно.
Но что произойдет, когда у нас появится повторитель? С точки зрения беспроводной сети повторитель – это еще один клиент, причем для обеспечения стабильного покрытия его следует размещать в пределах уверенного приема от точки доступа (50% перекрытия).
К чему это приводит? Как мы помним Wi-Fi работает по принципу – один говорит, остальные молчат. А повторитель у нас говорит два раза, как клиент основной точки и как точка для своего клиента. Т.е. занимает дополнительные слоты передачи.
Т.е. вместо одного устройства у нас как-бы появляется два. Вместо двух – четыре и т.д.
При этом сами устройства, подключенные через повторитель, потеряют где-то 50% полосы, так как одни и те же данные потребуется передавать в одном радиоканале два раза: от клиента к повторителю и от повторителя к точке (и точно также в обратном направлении).
Но, как мы уже сказали выше, страдать будут не только клиенты репитера, но и клиенты основной точки доступа за счет появления в сети паразитного дублирующегося трафика.
Простой и очень грубый пример: 4 устройства поделят между собой беспроводную полосу примерно поровну – по 25% на каждого.
Теперь берем 2 устройства напрямую и два через репитер. В результате полоса поделится уже на 6 устройств (два за репитером удваивают используемую полосу).
И опять-таки в идеальных условиях мы уже получим не 25, а 16% полосы на устройство.
До поры до времени, особенно если беспроводные устройства представлены нетребовательными клиентами и общей полосы хватает с запасом – это не заметно.
Но если мы начнем подключать к беспроводной сети требовательные устройства, например, телевизоры 2К – 4К, то это очень быстро станет заметно. Особенно если за репитер переместится несколько медленных клиентов, которые начнут отравлять жизнь всем остальным в два раза активнее.
Про цепочки из нескольких повторителей мы и говорить не хотим, фактически это приведет к кратному увеличению дублирующегося трафика и приведет к катастрофическому падению производительности сети.
💯14👍12🔥3👌2🤝1
Почему абонентская плата — это плохое решение?
В обсуждениях мы уже несколько раз получали вопросы от коллег: а как вы рассчитываете абонентскую плату?
Вопрос актуальный и животрепещущий, поэтому поделимся своим опытом. Мы уже давно от абонплаты как таковой отказались и сейчас расскажем почему.
Как обычно выглядит типовой договор на абонентное обслуживание? Это короткая бумага, где написано примерно следующее:
Исполнитель осуществляет абонентное технико-информационное обслуживание, включающее в себя: обслуживание программного обеспечения, принадлежащего Заказчику и услуги по обслуживанию компьютерной и оргтехники…
Дальше может идти перечень выполняемых работ в сильно размытом виде, а кто поумнее еще может попытаться ограничить верхнюю планку затраченных часов.
По сути, это «филькина грамота» ни о чем, потому как предмет договора сформулирован крайне размыто и может трактоваться в очень широком смысле. Фактически там написано: заплатите нам денег, а мы вам чего-нибудь поделаем.
Буквально сегодня читатель делился, мол предложил бывшему работодателю услуги исходя из расчета 10 часов по 2000 руб. тот отказался, сказал, что красная цена 3500 руб. В общем стороны расстались недовольные друг другом.
А теперь давайте посмотрим на эту картину со стороны заказчика. Некто предлагает ему ежемесячно платить 20 000 руб. за крайне размытый перечень услуг, большая часть которых заказчику непонятна, как контролировать их объем и качество он тоже не знает.
Но за эти же деньги он вполне может оформить на полставки бывшего студента, тот будет приходить на полдня в офис и пахать как лось, а контролировать сотрудника при этом гораздо проще.
При этом у такого договора есть и обратная сторона, ушлый заказчик может нагрузить вас по максимуму, умело играя на вашем желании сотрудничать с ним дальше, за пару месяцев привести у себя все в порядок, а потом сказать, что вы обходитесь ему слишком дорого.
В общем, как ни крути – ничего путевого из этой затеи не выйдет.
Как быть? Работать по факту? А если фактов не будет? Тоже писали, что за два года по факту заплатили как за два месяца обслуживания.
Поэтому нужно продавать заказчику не расплывчатую абонплату, а вполне осязаемые ценности. В виде пакетов, как это делают мобильные операторы.
Первое и самое востребованное – консультации. Звонить будут всегда. Вводим тариф: N часов консультаций – NNN рублей. Тарификация по 15 минут. Превышение – MMM руб./час, ну или купить еще один пакет.
Потом берем самые очевидные услуги: обновления, мониторинг, обращения. И на их базе тоже формируем пакеты. Если количество услуг и их характер понятен, то проще вообще их сделать фиксированными позициями прейскуранта. Так всем проще и понятнее для понимания.
Следующий вопрос: как продавать не явные услуги, например, профилактику или мониторинг. А здесь нужно четко донести до заказчика ценность простым русским языком. Мол сейчас вы обращаетесь по факту, что-то сломалось. А если поставим мониторинг, то сможем работать на опережение.
Но в этом случае вам придется действительно продавать мониторинг, т.е. предоставлять заказчику отчет в понятной форме, где будут указаны основные метрики и комментарии в норме они или есть отклонения.
Если были срабатывания триггеров, то тоже отражаем в отчете эти факты и принятые нами меры.
Продаем профилактику – даем отчет по профилактике.
Эти отчеты со стороны заказчика может никто не читать, но именно они дают представление о проделанной работе и обоснование заплаченных сумм.
И вот из этих самых пакетов мы и конструируем месячный тариф заказчика. Вполне очевидно, если вы трезво оценили объемы и свои способности – это получится примерно та же самая сумма.
Но только она будет экономически обоснована и состоять из набора относительно недорогих составляющих.
А такие счета всегда воспринимаются легче. Ну примерно, как вы берете чек в супермаркете, а там крупная сумма. Ого! Но начинаем смотреть по строкам и видим, что все нужное.
И в любом случае всегда ставьте себя на место заказчика, оплатили бы вы подобный счет?
В обсуждениях мы уже несколько раз получали вопросы от коллег: а как вы рассчитываете абонентскую плату?
Вопрос актуальный и животрепещущий, поэтому поделимся своим опытом. Мы уже давно от абонплаты как таковой отказались и сейчас расскажем почему.
Как обычно выглядит типовой договор на абонентное обслуживание? Это короткая бумага, где написано примерно следующее:
Исполнитель осуществляет абонентное технико-информационное обслуживание, включающее в себя: обслуживание программного обеспечения, принадлежащего Заказчику и услуги по обслуживанию компьютерной и оргтехники…
Дальше может идти перечень выполняемых работ в сильно размытом виде, а кто поумнее еще может попытаться ограничить верхнюю планку затраченных часов.
По сути, это «филькина грамота» ни о чем, потому как предмет договора сформулирован крайне размыто и может трактоваться в очень широком смысле. Фактически там написано: заплатите нам денег, а мы вам чего-нибудь поделаем.
Буквально сегодня читатель делился, мол предложил бывшему работодателю услуги исходя из расчета 10 часов по 2000 руб. тот отказался, сказал, что красная цена 3500 руб. В общем стороны расстались недовольные друг другом.
А теперь давайте посмотрим на эту картину со стороны заказчика. Некто предлагает ему ежемесячно платить 20 000 руб. за крайне размытый перечень услуг, большая часть которых заказчику непонятна, как контролировать их объем и качество он тоже не знает.
Но за эти же деньги он вполне может оформить на полставки бывшего студента, тот будет приходить на полдня в офис и пахать как лось, а контролировать сотрудника при этом гораздо проще.
При этом у такого договора есть и обратная сторона, ушлый заказчик может нагрузить вас по максимуму, умело играя на вашем желании сотрудничать с ним дальше, за пару месяцев привести у себя все в порядок, а потом сказать, что вы обходитесь ему слишком дорого.
В общем, как ни крути – ничего путевого из этой затеи не выйдет.
Как быть? Работать по факту? А если фактов не будет? Тоже писали, что за два года по факту заплатили как за два месяца обслуживания.
Поэтому нужно продавать заказчику не расплывчатую абонплату, а вполне осязаемые ценности. В виде пакетов, как это делают мобильные операторы.
Первое и самое востребованное – консультации. Звонить будут всегда. Вводим тариф: N часов консультаций – NNN рублей. Тарификация по 15 минут. Превышение – MMM руб./час, ну или купить еще один пакет.
Потом берем самые очевидные услуги: обновления, мониторинг, обращения. И на их базе тоже формируем пакеты. Если количество услуг и их характер понятен, то проще вообще их сделать фиксированными позициями прейскуранта. Так всем проще и понятнее для понимания.
Следующий вопрос: как продавать не явные услуги, например, профилактику или мониторинг. А здесь нужно четко донести до заказчика ценность простым русским языком. Мол сейчас вы обращаетесь по факту, что-то сломалось. А если поставим мониторинг, то сможем работать на опережение.
Но в этом случае вам придется действительно продавать мониторинг, т.е. предоставлять заказчику отчет в понятной форме, где будут указаны основные метрики и комментарии в норме они или есть отклонения.
Если были срабатывания триггеров, то тоже отражаем в отчете эти факты и принятые нами меры.
Продаем профилактику – даем отчет по профилактике.
Эти отчеты со стороны заказчика может никто не читать, но именно они дают представление о проделанной работе и обоснование заплаченных сумм.
И вот из этих самых пакетов мы и конструируем месячный тариф заказчика. Вполне очевидно, если вы трезво оценили объемы и свои способности – это получится примерно та же самая сумма.
Но только она будет экономически обоснована и состоять из набора относительно недорогих составляющих.
А такие счета всегда воспринимаются легче. Ну примерно, как вы берете чек в супермаркете, а там крупная сумма. Ого! Но начинаем смотреть по строкам и видим, что все нужное.
И в любом случае всегда ставьте себя на место заказчика, оплатили бы вы подобный счет?
👍18🤔11🥱4❤3
Узкий профиль или болото? Часть 2.
Продолжаем рассказ, написанный по моей просьбе коллегой, повествование идет от его лица.
В общем, поговорив с дядей я занялся внедрением современных технологий, прежде всего на те участки, где у нас были узкие места. А они были, прежде всего в оперативном обмене информацией между подразделениями.
И именно это больше всего тревожило собственника. Интернет-торговля уже начинала наступать на пятки и нас выручало в основном то, что отделочные и строительные материалы люди предпочитают посмотреть и потрогать перед покупкой.
У нас же выставочный зал представлял в основном образцы, плюс тут же был небольшой склад с мелочевкой. Остальное или на первом складе, километрах в трех от нас, или на производственной площадке, на другом конце города.
Обмен происходил штатными средствами 1С через РИБ, т.е. с задержкой в 15-20 минут. Но перед этим данные еще должны были попасть в 1С из нашей внутренней программы, которая взаимодействовала с 1С через COM и там тоже была задержка в 5-10 минут, в зависимости от объемов данных.
Все это приводило к тому, что данные из центрального офиса могли попасть на склады с задержкой до получаса. И это начало создавать серьезные сложности, особенно с постоянными клиентами из числа строительных бригад, у которых были лимиты на отгрузку без оплаты, которые могли динамически меняться в зависимости от объемов и платежной дисциплины.
А теперь представьте, клиент неправильно посчитал плитку, бригада на объекте, нужно срочно еще ящик-другой. Бригадир берет кусок плитки и едет сразу на склад. Находят нужную партию и дальше начинаются качели длинной в полчаса.
Со звонками, мол Маша, позвони ему и скажи пусть отгрузит, у меня лимит есть, мне сегодня этот объект закончить надо, там клей уже разведен… и т.д. и т.п.
А кладовщик: как накладная придет – так отгружу, извини, я материально ответственное лицо.
И этот вопрос никак на текущем стеке технологий не решался. Поэтому первым делом стали внедрять веб-сервисы. Просто не было, пришлось практически все изучать с нуля, для меня и моих коллег это буквально была новая планета.
Но справились и когда мы это внедрили даже в зачаточном состоянии, то получили эффект разорвавшейся бомбы. Все сразу начали спрашивать: а что, так можно было, и почему вы раньше так не сделали?
Теперь при наличии связи любой заказ, лимит или баланс виден в режиме реального времени. Это очень сильно подняло и нашу самооценку, и наш рейтинг в глазах руководства. Потому что мы решили одну из главных проблем и сразу же получили зеленый свет на дальнейшие действия.
А после мы занялись внутренней инфраструктурой, потому что там было что-то просто ужасающее.
К виртуализации у меня долгое время было отношение как к чему-то не для простых смертных. Ну да, работая в основном на Server 2003 / 2008 было немудрено.
В итоге на физических серверах в итоге собрались такие причудливые сочетания служб, что сам уже не понимал как оно там все устроено и работает. В полный рост применялся принцип: работает – не трогай.
Я не говорю уже про профилактику или апдейты, все это приходилось делать в глубоко нерабочее время и постоянно думать об одном: лишь бы взлетело.
В итоге младший персонал просто боялся что-то там трогать, и я невольно стал «незаменимым», что не нравилось ни мне, ни руководству.
Но посмотрев на виртуалки и контейнеры в деле я стал понемногу внедрять виртуализацию у себя по принципу «один сервис – одна виртуалка». Процесс тоже был довольно непрост. Зато теперь можно гибко управлять всей инфраструктурой не боясь, что обновление сервиса А завалит сервисы Б, В, Г, Д и далее по алфавиту.
Кроме того, появилась возможность разделить роли между сотрудниками. Этот отвечает за почту, этот за сайт, а этот за базы данных. У каждого свои виртуалки, свой объем работ и свой уровень ответственности.
И да, теперь я специалист самого широкого профиля и не являюсь незаменимым. Зато я могу спокойно уехать на две недели к морю и пить пиво на пляже, не вздрагивая от каждого звука из телефона
Продолжаем рассказ, написанный по моей просьбе коллегой, повествование идет от его лица.
В общем, поговорив с дядей я занялся внедрением современных технологий, прежде всего на те участки, где у нас были узкие места. А они были, прежде всего в оперативном обмене информацией между подразделениями.
И именно это больше всего тревожило собственника. Интернет-торговля уже начинала наступать на пятки и нас выручало в основном то, что отделочные и строительные материалы люди предпочитают посмотреть и потрогать перед покупкой.
У нас же выставочный зал представлял в основном образцы, плюс тут же был небольшой склад с мелочевкой. Остальное или на первом складе, километрах в трех от нас, или на производственной площадке, на другом конце города.
Обмен происходил штатными средствами 1С через РИБ, т.е. с задержкой в 15-20 минут. Но перед этим данные еще должны были попасть в 1С из нашей внутренней программы, которая взаимодействовала с 1С через COM и там тоже была задержка в 5-10 минут, в зависимости от объемов данных.
Все это приводило к тому, что данные из центрального офиса могли попасть на склады с задержкой до получаса. И это начало создавать серьезные сложности, особенно с постоянными клиентами из числа строительных бригад, у которых были лимиты на отгрузку без оплаты, которые могли динамически меняться в зависимости от объемов и платежной дисциплины.
А теперь представьте, клиент неправильно посчитал плитку, бригада на объекте, нужно срочно еще ящик-другой. Бригадир берет кусок плитки и едет сразу на склад. Находят нужную партию и дальше начинаются качели длинной в полчаса.
Со звонками, мол Маша, позвони ему и скажи пусть отгрузит, у меня лимит есть, мне сегодня этот объект закончить надо, там клей уже разведен… и т.д. и т.п.
А кладовщик: как накладная придет – так отгружу, извини, я материально ответственное лицо.
И этот вопрос никак на текущем стеке технологий не решался. Поэтому первым делом стали внедрять веб-сервисы. Просто не было, пришлось практически все изучать с нуля, для меня и моих коллег это буквально была новая планета.
Но справились и когда мы это внедрили даже в зачаточном состоянии, то получили эффект разорвавшейся бомбы. Все сразу начали спрашивать: а что, так можно было, и почему вы раньше так не сделали?
Теперь при наличии связи любой заказ, лимит или баланс виден в режиме реального времени. Это очень сильно подняло и нашу самооценку, и наш рейтинг в глазах руководства. Потому что мы решили одну из главных проблем и сразу же получили зеленый свет на дальнейшие действия.
А после мы занялись внутренней инфраструктурой, потому что там было что-то просто ужасающее.
К виртуализации у меня долгое время было отношение как к чему-то не для простых смертных. Ну да, работая в основном на Server 2003 / 2008 было немудрено.
В итоге на физических серверах в итоге собрались такие причудливые сочетания служб, что сам уже не понимал как оно там все устроено и работает. В полный рост применялся принцип: работает – не трогай.
Я не говорю уже про профилактику или апдейты, все это приходилось делать в глубоко нерабочее время и постоянно думать об одном: лишь бы взлетело.
В итоге младший персонал просто боялся что-то там трогать, и я невольно стал «незаменимым», что не нравилось ни мне, ни руководству.
Но посмотрев на виртуалки и контейнеры в деле я стал понемногу внедрять виртуализацию у себя по принципу «один сервис – одна виртуалка». Процесс тоже был довольно непрост. Зато теперь можно гибко управлять всей инфраструктурой не боясь, что обновление сервиса А завалит сервисы Б, В, Г, Д и далее по алфавиту.
Кроме того, появилась возможность разделить роли между сотрудниками. Этот отвечает за почту, этот за сайт, а этот за базы данных. У каждого свои виртуалки, свой объем работ и свой уровень ответственности.
И да, теперь я специалист самого широкого профиля и не являюсь незаменимым. Зато я могу спокойно уехать на две недели к морю и пить пиво на пляже, не вздрагивая от каждого звука из телефона
👍22🥱5❤2🤮2🤔1
Про почасовку
Очень часто на канале возникают вопросы по этой теме. Тема важная и нужная, поэтому поделимся своим опытом.
А начнем с того, что, если вы не хотите сразу испортить отношения с заказчиком и перевести их в плоскость постоянных разбирательств – никогда не выставляйте ему часы, за редким исключением.
Для исполнителя часы – единица удобная, особенно если приходится делать какую-то новую работу. Оценил затраченное время, умножил на тариф и вот он финансовый результат.
Но здесь тоже есть свои тонкости. Если сначала эта работа занимала у вас два часа, потом вы набили руку и стали укладываться в час. Снижать цену?
Или вы написали скрипт, который все делает за вас. Тут тоже заказчик может задать вопрос – а за какие часы я плачу? Если ты только два раза по файлу кликнул, а потом сидел смотрел в экран?
И он тоже по-своему будет прав. Выставляя в счете часы, вы как бы заявляете, что продаете не услугу, у которой есть конечный результат и он является предметом оплаты, а свое рабочее время.
А если выставили время, то будьте добры его отработать. Или сократить свои хотелки согласно реально отработанного времени.
Мы не раз и не два сталкивались с конфликтами, когда внедренец по ТЗ выставлял, скажем, 200-250 часов, закрывал их силами одного специалиста за месяц, а после чего заказчик отказывался оплачивать счет и настойчиво интересовался, каким образом это физически стало возможно. Может специалист там на цепи сидит?
Может он в чем-то не прав? Может. Потому что в нашей отрасли час давно перестал быть физическим часом и служит неким средним мерилом по отрасли. Мол средний специалист средней квалификации сделает эту работу за час. А наш ведущий потратит всего 15 минут.
Можно, конечно, повысить стоимость часа, но это отпугнет заказчика. В итоге задача подгоняется под ответ. Исходя из среднего часа на местности подгоняются временные рамки, чтобы получить нужный экономический выхлоп от задачи.
Поэтому, никогда и ни при каких обстоятельствах не выставляйте заказчику часы. Нигде. Ни в смете, ни в техзадании. Вообще нигде.
При этом внутри своей кухни вы можете по-прежнему их использовать для оценки стоимости работ.
Но наружу вместо часов вы должны выставлять услугу. Услуга – это законченное действие, имеющее четкий, заранее оговоренный результат, который принимает заказчик. И фиксированную стоимость.
А дальше уже не важно сколько времени вы потратили на ее реализацию. Обещали неделю, а справились за три дня – молодцы, сразу видно настоящих профессионалов! А цена? Какой была – такой осталась. Заказчик платит за результат.
Набили руку, стали делать работу за час вместо двух? Отлично, эффективность повысилась, по деньгам вы не просели, и никто даже не подумает задавать подобные вопросы.
Договаривались на что? На результат. Вот результат. Вот деньги. Все просто, понятно, прозрачно. И заказчик еще на берегу понимает за что платит. Цена устраивает? Значит работаем.
Единственные случаи, когда выставлять часы нормально и естественно, это работы или услуги, непосредственно завязанные по времени.
Например, вы проводите обучение сотрудников заказчика. Договорились на два часа: час лекция, час ответы на вопросы. В итоге все растянулось на три. Не вопрос, выставляем в счете три часа, вопросов ни у кого не будет, все всё понимают.
Во всех остальных случаях, когда используемый вами человеко/час является неким средним по палате он должен всегда превращаться в штуки, литры, килограммы – т.е. в некую конечную единицу, которую вы отгрузите заказчику и которая будет ему понятна.
Очень часто на канале возникают вопросы по этой теме. Тема важная и нужная, поэтому поделимся своим опытом.
А начнем с того, что, если вы не хотите сразу испортить отношения с заказчиком и перевести их в плоскость постоянных разбирательств – никогда не выставляйте ему часы, за редким исключением.
Для исполнителя часы – единица удобная, особенно если приходится делать какую-то новую работу. Оценил затраченное время, умножил на тариф и вот он финансовый результат.
Но здесь тоже есть свои тонкости. Если сначала эта работа занимала у вас два часа, потом вы набили руку и стали укладываться в час. Снижать цену?
Или вы написали скрипт, который все делает за вас. Тут тоже заказчик может задать вопрос – а за какие часы я плачу? Если ты только два раза по файлу кликнул, а потом сидел смотрел в экран?
И он тоже по-своему будет прав. Выставляя в счете часы, вы как бы заявляете, что продаете не услугу, у которой есть конечный результат и он является предметом оплаты, а свое рабочее время.
А если выставили время, то будьте добры его отработать. Или сократить свои хотелки согласно реально отработанного времени.
Мы не раз и не два сталкивались с конфликтами, когда внедренец по ТЗ выставлял, скажем, 200-250 часов, закрывал их силами одного специалиста за месяц, а после чего заказчик отказывался оплачивать счет и настойчиво интересовался, каким образом это физически стало возможно. Может специалист там на цепи сидит?
Может он в чем-то не прав? Может. Потому что в нашей отрасли час давно перестал быть физическим часом и служит неким средним мерилом по отрасли. Мол средний специалист средней квалификации сделает эту работу за час. А наш ведущий потратит всего 15 минут.
Можно, конечно, повысить стоимость часа, но это отпугнет заказчика. В итоге задача подгоняется под ответ. Исходя из среднего часа на местности подгоняются временные рамки, чтобы получить нужный экономический выхлоп от задачи.
Поэтому, никогда и ни при каких обстоятельствах не выставляйте заказчику часы. Нигде. Ни в смете, ни в техзадании. Вообще нигде.
При этом внутри своей кухни вы можете по-прежнему их использовать для оценки стоимости работ.
Но наружу вместо часов вы должны выставлять услугу. Услуга – это законченное действие, имеющее четкий, заранее оговоренный результат, который принимает заказчик. И фиксированную стоимость.
А дальше уже не важно сколько времени вы потратили на ее реализацию. Обещали неделю, а справились за три дня – молодцы, сразу видно настоящих профессионалов! А цена? Какой была – такой осталась. Заказчик платит за результат.
Набили руку, стали делать работу за час вместо двух? Отлично, эффективность повысилась, по деньгам вы не просели, и никто даже не подумает задавать подобные вопросы.
Договаривались на что? На результат. Вот результат. Вот деньги. Все просто, понятно, прозрачно. И заказчик еще на берегу понимает за что платит. Цена устраивает? Значит работаем.
Единственные случаи, когда выставлять часы нормально и естественно, это работы или услуги, непосредственно завязанные по времени.
Например, вы проводите обучение сотрудников заказчика. Договорились на два часа: час лекция, час ответы на вопросы. В итоге все растянулось на три. Не вопрос, выставляем в счете три часа, вопросов ни у кого не будет, все всё понимают.
Во всех остальных случаях, когда используемый вами человеко/час является неким средним по палате он должен всегда превращаться в штуки, литры, килограммы – т.е. в некую конечную единицу, которую вы отгрузите заказчику и которая будет ему понятна.
👍20❤1👨💻1
Узкий профиль или болото? Заключение.
В прошлых заметках мы обсуждали ситуацию, когда используемый стек технологий негативно отражается на развитии специалиста и приводит к фактическому застою.
Начнем с того, что сфера IT во всех ее проявлениях весьма динамична и здесь, как в Алисе: «Нужно бежать со всех ног, чтобы только оставаться на месте»
Если вы выпадаете на несколько лет из актуальной повестки, то можете уже не узнать окружающую вас реальность, все будут говорить о чем-то непонятном и смотреть на вас как на динозавра.
Хорошо, если вы сможете быстро адаптироваться и устранить пробелы, а если такой возможности нет? В таком случае вы выпадаете не только из технологий, но и с рынка труда, где уже не можете претендовать на серьезные вакансии, а на начальный уровень скорее возьмут молодого мальчика, чем взрослого дядьку.
На первое место среди кладбищ кадров я бы поставил бюджетные организации. Там не только прекращается развитие специалиста, но и вообще прививаются крайне вредные привычки, вроде имитации работы и написания красивых отчетов.
В бюджетке важно, чтобы все было прикрыто бумагами и худо-бедно работало. А если не работает, то обязательно по уважительной причине, отраженной в куче отчетов, докладных записок и т.д.
Я сам на заре трудовой деятельности отработал два года в сельскохозяйственном НИИ и прекрасно освоил процесс имитации бурной деятельности. А реальная работа могла сутками стоять, потому что есть «гораздо более важные» дела.
Второй бич бюджетки – это отношения «ты начальник – я дурак, я начальник – ты дурак» и связанные с ними бесконечные согласования, обсуждения и т.п. После того, как я ушел оттуда в частную фирму мой новый начальник еще с полгода закрывал лицо рукой и устало произносил: «ну когда ты начнешь работать самостоятельно???»
В коммерции все немного бодрее, но до поры до времени. После того как найдена некая оптимальная конфигурация IT-инфраструктуры наступает пора стабилизации и это нормально. Но очень часто она выливается в застой.
Появляется определенная зона комфорта. Действительно, а зачем учить что-то новое, если и так все работает? Зачем что-то внедрять, рисковать, тратить время и нервы, когда можно ничего не делать и получать те же деньги?
Вот так, незаметно, стабильность сменяется застоем, а некогда актуальная инфраструктура начинает стремительно устаревать. Причем чем дольше заметать пыль под ковер, делая вид что все хорошо, то тем хуже становится в последствии.
Обычно то, что с IT что-то не так до руководства доходит слишком поздно, когда начинают ломаться бизнес-процессы или возникает серьезная проблема с внедрением нововведений, как законодательных, так и сервисных, призванных улучшить обслуживание клиентов или внутренних подразделений.
В этом случае выясняется, что проще все сломать и построить заново, нежели приводить то, что есть в порядок и вряд ли ваша карьера в этом месте продолжит дальше катиться по накатанной.
Ну и третья категория, это «узкие» специалисты. Тут вообще разговор отдельный, более проходящий по теме религиозного фанатизма, нежели информационных технологий.
Это любители ставить в продакшен Gentoo, FreeBSD, Solaris и тому подобную экзотику, прекрасно понимая, что в обозримом пространстве специалистов по этой системе не найти и они вроде как на коне.
Проблемы начинаются, когда список задач выходит за пределы знаний и умений такого специалиста, а приглашенные со стороны либо умывают руки, либо выставляют космический прайс.
Я понимаю, что редкий стек – это греет душу и поднимает самооценку, но, будем смотреть правде в глаза – на рынке труда стоимость этих знаний близка к нулю.
Вот сейчас поиск на HH по слову Linux показывает в Москве 7303 вакансии, по слову FreeBSD – всего 44. И это при том, что коммерческая разработка у нас нацелена на DEB/RPM и нестандартная ОС автоматически означает отсутствие официальной поддержки.
Поэтому, коллеги, трезво оцените свое положение и если вы все такие попали в описанное выше болото, то найдите силы это признать и начинайте из него выбираться.
В прошлых заметках мы обсуждали ситуацию, когда используемый стек технологий негативно отражается на развитии специалиста и приводит к фактическому застою.
Начнем с того, что сфера IT во всех ее проявлениях весьма динамична и здесь, как в Алисе: «Нужно бежать со всех ног, чтобы только оставаться на месте»
Если вы выпадаете на несколько лет из актуальной повестки, то можете уже не узнать окружающую вас реальность, все будут говорить о чем-то непонятном и смотреть на вас как на динозавра.
Хорошо, если вы сможете быстро адаптироваться и устранить пробелы, а если такой возможности нет? В таком случае вы выпадаете не только из технологий, но и с рынка труда, где уже не можете претендовать на серьезные вакансии, а на начальный уровень скорее возьмут молодого мальчика, чем взрослого дядьку.
На первое место среди кладбищ кадров я бы поставил бюджетные организации. Там не только прекращается развитие специалиста, но и вообще прививаются крайне вредные привычки, вроде имитации работы и написания красивых отчетов.
В бюджетке важно, чтобы все было прикрыто бумагами и худо-бедно работало. А если не работает, то обязательно по уважительной причине, отраженной в куче отчетов, докладных записок и т.д.
Я сам на заре трудовой деятельности отработал два года в сельскохозяйственном НИИ и прекрасно освоил процесс имитации бурной деятельности. А реальная работа могла сутками стоять, потому что есть «гораздо более важные» дела.
Второй бич бюджетки – это отношения «ты начальник – я дурак, я начальник – ты дурак» и связанные с ними бесконечные согласования, обсуждения и т.п. После того, как я ушел оттуда в частную фирму мой новый начальник еще с полгода закрывал лицо рукой и устало произносил: «ну когда ты начнешь работать самостоятельно???»
В коммерции все немного бодрее, но до поры до времени. После того как найдена некая оптимальная конфигурация IT-инфраструктуры наступает пора стабилизации и это нормально. Но очень часто она выливается в застой.
Появляется определенная зона комфорта. Действительно, а зачем учить что-то новое, если и так все работает? Зачем что-то внедрять, рисковать, тратить время и нервы, когда можно ничего не делать и получать те же деньги?
Вот так, незаметно, стабильность сменяется застоем, а некогда актуальная инфраструктура начинает стремительно устаревать. Причем чем дольше заметать пыль под ковер, делая вид что все хорошо, то тем хуже становится в последствии.
Обычно то, что с IT что-то не так до руководства доходит слишком поздно, когда начинают ломаться бизнес-процессы или возникает серьезная проблема с внедрением нововведений, как законодательных, так и сервисных, призванных улучшить обслуживание клиентов или внутренних подразделений.
В этом случае выясняется, что проще все сломать и построить заново, нежели приводить то, что есть в порядок и вряд ли ваша карьера в этом месте продолжит дальше катиться по накатанной.
Ну и третья категория, это «узкие» специалисты. Тут вообще разговор отдельный, более проходящий по теме религиозного фанатизма, нежели информационных технологий.
Это любители ставить в продакшен Gentoo, FreeBSD, Solaris и тому подобную экзотику, прекрасно понимая, что в обозримом пространстве специалистов по этой системе не найти и они вроде как на коне.
Проблемы начинаются, когда список задач выходит за пределы знаний и умений такого специалиста, а приглашенные со стороны либо умывают руки, либо выставляют космический прайс.
Я понимаю, что редкий стек – это греет душу и поднимает самооценку, но, будем смотреть правде в глаза – на рынке труда стоимость этих знаний близка к нулю.
Вот сейчас поиск на HH по слову Linux показывает в Москве 7303 вакансии, по слову FreeBSD – всего 44. И это при том, что коммерческая разработка у нас нацелена на DEB/RPM и нестандартная ОС автоматически означает отсутствие официальной поддержки.
Поэтому, коллеги, трезво оцените свое положение и если вы все такие попали в описанное выше болото, то найдите силы это признать и начинайте из него выбираться.
👍22🤮5🤔2👎1👌1
Бег в колесе, как спрыгнуть?
После публикации заметок про болото читатели начали задавать вопросы: мол все что написано – это хорошо, но нет ни слова о том, как спрыгнуть. И привели типичный пример попавшего в болото специалиста, который обременен семьей, кредитами, ипотеками, упахивается текучкой на работе и еще успевает калымить за мелкий прайс.
И так день за днем, неделя за неделей, потом проходят года, мы не молодеем, а отрыв от актуальных технологий растет и ширится. Поэтому вполне справедливо возникает вопрос: «Что делать?».
Во-первых, такую ситуацию надо осознать и принять, что бывает достаточно тяжело, никто не любит признавать собственные неудачи. Но без этого практически невозможно выйти из зоны комфорта, только если ситуация начнет вас тяготить, то появится стимул для ее исправления.
А для этого достаточно сесть и подумать: а что я буду делать через 10 лет? Или куда я пойду, если моя контора завтра закроется?
Также рекомендуется внимательно изучить вакансии на том же HH и примерить их на себя. Если не примеряется – следовательно вы выпали с рынка и надо что-то делать.
Оптимальный вариант – это начать изменения с текущего места работы. Выявить слабые места, сложности, проблемы и подумать, как бы можно было их решить и при помощи каких технологий.
В целом бизнес, если у него есть деньги, достаточно положительно воспринимает подобные инициативы снизу, только вот предлагать их нужно не техническим языком, а языком бизнеса.
Т.е. не говорить: «Насяльника, дай денег, новый сервер покупать надо, однако…», в этом случае вам никто ничего не даст, разве что догонят и добавят. А приходить с четким анализом, мол есть у нас проблема, приводит к таким-то сложностям в таком-то бизнес-процессе. Связано с тем-то и тем-то, можно решить внедрив то-то и то-то.
Это хороший вариант, но бывает, что владелец бизнеса сидит в таком же болоте и точно также бежит как белка, но уже в своем колесе. Вроде бы и надо бизнес развивать, но тут и кредиты, и стройка, жена, дети, теща… В общем все тоже самое, только на несколько другом финансовом уровне.
По-хорошему с такой работы надо уходить, пусть на аналогичную з/п, но туда, где спокойнее и есть хоть какие-то деньги на развитие.
Если же такой возможности нет, то надо пересматривать структуру доходов. Прежде всего начать откладывать, чтобы была финансовая подушка. Делать это через себя, через «нечего отложить» как бы сложно не было. Что-то отложить можно всегда.
А еще займитесь домашней бухгалтерией, скрупулезно вносите расходы и узнаете много интересного. А заодно найдете источники для накоплений.
И важное – прекратите калымить за мелкий прайс, оставьте это студентам. По опыту могу сказать, что такие заказчики сильнее всего выносят мозг. И вы этой тысяче будете просто не рады, а скорее всего сработаете себе в убыток.
Установите фиксированную стоимость часа, хотя бы на уровне 1000 рублей и придерживайтесь того, что все ваше время должно быть оплачено, в т.ч. и то, что ушло на дорогу.
Что? Клиенты откажутся? Да и пес с ними. Потому как приехать, посмотреть регистратор, потом кабанчиком метнуться в магазин за новым диском, поменять, все пояснить-разъяснить и потратить три часа за тысячу-полторы заодно выслушивая недовольство заказчика – это явно игра с отрицательным результатом.
И отношения тут надо перестраивать. В данном случае вы не наемный рабочий, а равноправный партнер в гражданско-правовых отношениях. Не нравятся условия сотрудничества – рынок большой, походи, может найдешь, где лучше.
Надо срочно? Срочность оплачивается отдельно. Хочешь поорать? Дома на жену поори. Приехать? Дорога оплачивается. Поехать купить? Так тоже не бесплатно. Не нравится – привози железо сам и оплачивай доставку из магазина.
Но так делать страшно. Потому что большая часть заказчиков, которую вы приучили к мелкому прайсу разбежится, причем в крайнем изумлении и со словами: «Этот Иванов что-то в край офигел». Ну да тут сами виноваты, приучили к халяве и своему подчиненному положению.
После публикации заметок про болото читатели начали задавать вопросы: мол все что написано – это хорошо, но нет ни слова о том, как спрыгнуть. И привели типичный пример попавшего в болото специалиста, который обременен семьей, кредитами, ипотеками, упахивается текучкой на работе и еще успевает калымить за мелкий прайс.
И так день за днем, неделя за неделей, потом проходят года, мы не молодеем, а отрыв от актуальных технологий растет и ширится. Поэтому вполне справедливо возникает вопрос: «Что делать?».
Во-первых, такую ситуацию надо осознать и принять, что бывает достаточно тяжело, никто не любит признавать собственные неудачи. Но без этого практически невозможно выйти из зоны комфорта, только если ситуация начнет вас тяготить, то появится стимул для ее исправления.
А для этого достаточно сесть и подумать: а что я буду делать через 10 лет? Или куда я пойду, если моя контора завтра закроется?
Также рекомендуется внимательно изучить вакансии на том же HH и примерить их на себя. Если не примеряется – следовательно вы выпали с рынка и надо что-то делать.
Оптимальный вариант – это начать изменения с текущего места работы. Выявить слабые места, сложности, проблемы и подумать, как бы можно было их решить и при помощи каких технологий.
В целом бизнес, если у него есть деньги, достаточно положительно воспринимает подобные инициативы снизу, только вот предлагать их нужно не техническим языком, а языком бизнеса.
Т.е. не говорить: «Насяльника, дай денег, новый сервер покупать надо, однако…», в этом случае вам никто ничего не даст, разве что догонят и добавят. А приходить с четким анализом, мол есть у нас проблема, приводит к таким-то сложностям в таком-то бизнес-процессе. Связано с тем-то и тем-то, можно решить внедрив то-то и то-то.
Это хороший вариант, но бывает, что владелец бизнеса сидит в таком же болоте и точно также бежит как белка, но уже в своем колесе. Вроде бы и надо бизнес развивать, но тут и кредиты, и стройка, жена, дети, теща… В общем все тоже самое, только на несколько другом финансовом уровне.
По-хорошему с такой работы надо уходить, пусть на аналогичную з/п, но туда, где спокойнее и есть хоть какие-то деньги на развитие.
Если же такой возможности нет, то надо пересматривать структуру доходов. Прежде всего начать откладывать, чтобы была финансовая подушка. Делать это через себя, через «нечего отложить» как бы сложно не было. Что-то отложить можно всегда.
А еще займитесь домашней бухгалтерией, скрупулезно вносите расходы и узнаете много интересного. А заодно найдете источники для накоплений.
И важное – прекратите калымить за мелкий прайс, оставьте это студентам. По опыту могу сказать, что такие заказчики сильнее всего выносят мозг. И вы этой тысяче будете просто не рады, а скорее всего сработаете себе в убыток.
Установите фиксированную стоимость часа, хотя бы на уровне 1000 рублей и придерживайтесь того, что все ваше время должно быть оплачено, в т.ч. и то, что ушло на дорогу.
Что? Клиенты откажутся? Да и пес с ними. Потому как приехать, посмотреть регистратор, потом кабанчиком метнуться в магазин за новым диском, поменять, все пояснить-разъяснить и потратить три часа за тысячу-полторы заодно выслушивая недовольство заказчика – это явно игра с отрицательным результатом.
И отношения тут надо перестраивать. В данном случае вы не наемный рабочий, а равноправный партнер в гражданско-правовых отношениях. Не нравятся условия сотрудничества – рынок большой, походи, может найдешь, где лучше.
Надо срочно? Срочность оплачивается отдельно. Хочешь поорать? Дома на жену поори. Приехать? Дорога оплачивается. Поехать купить? Так тоже не бесплатно. Не нравится – привози железо сам и оплачивай доставку из магазина.
Но так делать страшно. Потому что большая часть заказчиков, которую вы приучили к мелкому прайсу разбежится, причем в крайнем изумлении и со словами: «Этот Иванов что-то в край офигел». Ну да тут сами виноваты, приучили к халяве и своему подчиненному положению.
👍31❤3👀3
Большой опрос
Вернулся из очередного отпуска. Как всегда, пришлось брать с собой ноутбук, сын тоже был с ноутбуком. Заодно на других посмотрел, с кем-то даже пообщался.
Заодно посидел, подумал и сделал некоторые выводы, для себя, на будущее.
В этой связи возникли некоторые вопросы, по которым хочется получить как статистику, так и обратную связь.
Чтобы не размывать обсуждение все комментарии под этим постом, под опросами комментарии будут выключены.
Вернулся из очередного отпуска. Как всегда, пришлось брать с собой ноутбук, сын тоже был с ноутбуком. Заодно на других посмотрел, с кем-то даже пообщался.
Заодно посидел, подумал и сделал некоторые выводы, для себя, на будущее.
В этой связи возникли некоторые вопросы, по которым хочется получить как статистику, так и обратную связь.
Чтобы не размывать обсуждение все комментарии под этим постом, под опросами комментарии будут выключены.
🤔4👍1🤮1
Большой 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 МБ/с.
Что из этого лучше? Однозначного мнения тут нет и быть не может. Все зависит от сценариев работы. В первом случае вы сможете принять на полной скорости примерно треть свободного объема диска, но потом получите скорость улитки, попавшей в студень.
Во-втором на полной скорости получится записать лишь небольшой объем данных, но за пределами кеша также будет сохраняться вполне комфортная скорость.
Поэтому если ваши сценарии предусматривают запись значительных объемов данных, то дополнительно будет неплохо почитать обзоры и выяснить алгоритмы кеширования выбранного диска.
При этом помните, что это сугубо программная настройка. И на рынке присутствует множество моделей абсолютно одинаковых аппаратно, но имеющие разные алгоритмы кеширования и, соответственно, разные скоростные характеристики.
Сегодня основным типом твердотельного накопителя является накопитель с типом ячеек 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 МБ/с.
Что из этого лучше? Однозначного мнения тут нет и быть не может. Все зависит от сценариев работы. В первом случае вы сможете принять на полной скорости примерно треть свободного объема диска, но потом получите скорость улитки, попавшей в студень.
Во-втором на полной скорости получится записать лишь небольшой объем данных, но за пределами кеша также будет сохраняться вполне комфортная скорость.
Поэтому если ваши сценарии предусматривают запись значительных объемов данных, то дополнительно будет неплохо почитать обзоры и выяснить алгоритмы кеширования выбранного диска.
При этом помните, что это сугубо программная настройка. И на рынке присутствует множество моделей абсолютно одинаковых аппаратно, но имеющие разные алгоритмы кеширования и, соответственно, разные скоростные характеристики.
👍13❤3
Укажите наиболее часто используемый, можно выбрать несколько вариантов
Anonymous Poll
32%
VMware
30%
Hyper‑V
64%
Proxmox VE
10%
Linux KVM
1%
XenServer
1%
XCP-ng
5%
Российские гипервизоры
1%
Bhyve
1%
Другое (напишу в комментариях)
5%
Просто посмотреть ответы
👍2❤1
Завершающий слеш в путях Linux
Данному вопросу часто не уделяют должного внимания и зря, он не так прост, как кажется, поэтому мы решили уделить ему отдельную заметку.
В Linux символом разделения каталогов является слеш, если после имени файла стоит этот символ, то подразумевается, что данный файл является каталогом. А в Linux, как мы помним, всё есть файл.
Также в Linux очень часто обходятся без расширения имен файлов, потому как тип файла определяется по содержимому (сейчас мы не берем во внимание графические оболочки). Поэтому запись:
Может быть как файлом, так и каталогом. Если же мы напишем так, то перед нами предположительно каталог:
Почему предположительно? Потому что мы можем написать слеш и после имени файла, но если мы попробуем выполнить с ним любую файловую операцию, то система выдаст нам ошибку, потому как данный файл не является каталогом.
Т.е. закрывающий слеш – не императив, а всего лишь указатель на предполагаемый тип файла. Его отсутствие вызывает состояние неопределенности, что может привести к некоторым казусам.
Например, в нашем скрипте написано в цикле что-то вроде:
Данная конструкция имеет неопределенность, потому что если мы забудем создать папку
Если же мы напишем:
То при отсутствии директории получим ошибку:
Если же мы попробуем указать вместо каталога обычный файл, например, там действительно существует файл
Т.е. систему не обмануть, и она всегда при файловой операции проверит тип файла, независимо от того поставили вы закрывающий слеш или нет.
Но наличие слеша устраняет неопределенность, потому что явно предписывает системе работать с путем как с каталогом и никак иначе. Кстати, при автоподстановке по Tab пути к каталогам сразу дополняются закрывающим слешем.
Достаточно ли просто добавить завершающий слеш в путь скрипта? А вот здесь все не так просто. Да, мы уберем неопределенность, да получим ошибку. Но что, если это случится уже после того, как скрипт отлажен и запущен в работу? Допустим целевой каталог переместили, переименовали или удалили?
В этом случае мы получим ошибку, запишем ее в лог и дальше? А дальше вопрос, когда именно администратор его прочитает. Ведь все мы любим читать логи за чашкой утреннего кофе, не правда-ли?
Поэтому в скриптах такие вещи всегда лучше проверять явно, например:
В данном случае мы проверили существование каталога и создали его при отсутствии, но никто не мешает выполнить и другие действия, скажем, направить сообщение на почту администратора и прекратить работу скрипта.
В любом случае это лучше, чем просто получить ошибку (или даже многочисленные ошибки) выполнения с записью в лог.
А после того, как мы выполнили подобную проверку и предприняли явные действия, то там уже становится все равно, есть закрывающий слеш в команде перемещения или нет.
Данному вопросу часто не уделяют должного внимания и зря, он не так прост, как кажется, поэтому мы решили уделить ему отдельную заметку.
В Linux символом разделения каталогов является слеш, если после имени файла стоит этот символ, то подразумевается, что данный файл является каталогом. А в Linux, как мы помним, всё есть файл.
Также в Linux очень часто обходятся без расширения имен файлов, потому как тип файла определяется по содержимому (сейчас мы не берем во внимание графические оболочки). Поэтому запись:
~/video
Может быть как файлом, так и каталогом. Если же мы напишем так, то перед нами предположительно каталог:
~/video/
Почему предположительно? Потому что мы можем написать слеш и после имени файла, но если мы попробуем выполнить с ним любую файловую операцию, то система выдаст нам ошибку, потому как данный файл не является каталогом.
Т.е. закрывающий слеш – не императив, а всего лишь указатель на предполагаемый тип файла. Его отсутствие вызывает состояние неопределенности, что может привести к некоторым казусам.
Например, в нашем скрипте написано в цикле что-то вроде:
mv -f "$file" /new_path/video
Данная конструкция имеет неопределенность, потому что если мы забудем создать папку
video, то все файлы будут перемещены в новый файл video и последовательно его перезапишут. Т.е. мы останемся без видео, у нас сохранится только последний файл.Если же мы напишем:
mv -f "$file" /new_path/video/
То при отсутствии директории получим ошибку:
mv: невозможно создать обычный файл ' video/': Это не каталог
Если же мы попробуем указать вместо каталога обычный файл, например, там действительно существует файл
video, скажем как результат предыдущего ошибочного запуска скрипта, то ошибка будет иной:mv: не удалось получить доступ к ' video /': Это не каталог
Т.е. систему не обмануть, и она всегда при файловой операции проверит тип файла, независимо от того поставили вы закрывающий слеш или нет.
Но наличие слеша устраняет неопределенность, потому что явно предписывает системе работать с путем как с каталогом и никак иначе. Кстати, при автоподстановке по Tab пути к каталогам сразу дополняются закрывающим слешем.
Достаточно ли просто добавить завершающий слеш в путь скрипта? А вот здесь все не так просто. Да, мы уберем неопределенность, да получим ошибку. Но что, если это случится уже после того, как скрипт отлажен и запущен в работу? Допустим целевой каталог переместили, переименовали или удалили?
В этом случае мы получим ошибку, запишем ее в лог и дальше? А дальше вопрос, когда именно администратор его прочитает. Ведь все мы любим читать логи за чашкой утреннего кофе, не правда-ли?
Поэтому в скриптах такие вещи всегда лучше проверять явно, например:
if ! [ -d /new_path/video/ ]; then
mkdir -p /new_path/video
fi
В данном случае мы проверили существование каталога и создали его при отсутствии, но никто не мешает выполнить и другие действия, скажем, направить сообщение на почту администратора и прекратить работу скрипта.
В любом случае это лучше, чем просто получить ошибку (или даже многочисленные ошибки) выполнения с записью в лог.
А после того, как мы выполнили подобную проверку и предприняли явные действия, то там уже становится все равно, есть закрывающий слеш в команде перемещения или нет.
👍19👌5❤4🔥2
Самозаверенные сертификаты. Мифы и реальность.
Самозаверенные, они же самозаверяющие или самоподписанные сертификаты являются предметом многих расхожих мифов. Основной их смысл сводится к тому, что такие сертификаты жутко небезопасны и выставить наружу ресурс с таким сертификатом – это все равно, что без сертификата вообще.
Но это мнение не имеет под собой никакого основания, так как сертификат сам по себе не определяет стойкость шифрования — за выбор протоколов и шифронаборов отвечают настройки сервера и клиента.
Кроме того, следует помнить, что выбор шифра – процесс обоюдный и недаром называется согласованием. В процессе установления соединения клиент получает от сервера список поддерживаемых шифров и выбирает самый стойкий из тех, которые поддерживает сам.
Если клиент не поддерживает ни один из предложенных шифров, то соединение установить не удастся. Но и наоборот, существуют специальные атаки на понижение шифрования, цель которых согласовать старый и нестойкий шифр. Поэтому предлагаемый набор шифров — это всегда компромисс между совместимостью и безопасностью.
Так мы можем иметь «настоящий» сертификат и слабый набор шифров ради обеспечения совместимости с устаревшими клиентами или, наоборот, самоподписанный сертификат с небольшим набором самых современных криптографических алгоритмов. И вторая система будет обеспечивать гораздо более высокий уровень безопасности чем первая.
Так чем же плох самоподписанный сертификат? Тем, что с ним невозможно установить отношения доверия, которые являются ключевыми во всей современной криптографии. Проще говоря, устанавливая защищенное соединение мы хотим быть уверены, что сертификат действительно принадлежит указанному владельцу, а не третьему лицу.
Чтобы помочь нам в этом вопросе существуют центры сертификации, авторитет которых не подлежит сомнению, и, если сертификат подписан одним из этих CA, то доверие к центру сертификации распространяется на сертификат, и мы тоже можем ему доверять.
Для проверки доверия все центры сертификации выпускают собственные корневые сертификаты, которые позволяют убедиться, что сертификат выпущен именно этим издателем.
Корневые сертификаты известных издателей распространяются вместе с ОС и хранятся в особом системном хранилище, исключающем их случайную подмену.
Здесь существует один парадокс. Корневой сертификат удостоверяющего центра не является секретным, но доступ к нему в системе должен быть ограничен, так как в противном случае возможна атака типа человек посередине, и вы автоматически примете сертификат, подписанный злоумышленником.
По этой же причине требуется крайне внимательно относиться к сертификатам, которые вы устанавливаете в качестве доверенных корневых центров сертификации, так как после его установки вы будете автоматически доверять всем сертификатам, выпущенным этим центром.
Также не следует путать самозаверенные сертификаты с сертификатами частных центров сертификации, например, корпоративным CA. С последними можно легко установить доверительные отношения (если вы действительно им доверяете) просто установив в систему нужный корневой сертификат.
Самозаверенный сертификат не имеет доверенного центра сертификации в цепочке и доверительные отношения с ним установить не удастся, все, что мы можем – это добавить его в исключения, чтобы не получать уведомлений системы безопасности.
Но это нужно сделать на каждой системе, при этом обязательно проверив, тот ли это сертификат по отпечатку подписи. Но это способен сделать далеко не каждый пользователь и на практике даже добавления в исключения часто не происходит. Чаще всего предупреждение безопасности просто игнорируется, что является крайне плохой практикой, так как вам спокойно могут подменить сертификат, а вы даже не заметите.
Подведем итог: самозаверенный сертификат с точки зрения шифрования столь же безопасен, как и любой другой. Основная его проблема – это невозможность установить доверительные отношения и однозначно доверять ему без дополнительных проверок.
Самозаверенные, они же самозаверяющие или самоподписанные сертификаты являются предметом многих расхожих мифов. Основной их смысл сводится к тому, что такие сертификаты жутко небезопасны и выставить наружу ресурс с таким сертификатом – это все равно, что без сертификата вообще.
Но это мнение не имеет под собой никакого основания, так как сертификат сам по себе не определяет стойкость шифрования — за выбор протоколов и шифронаборов отвечают настройки сервера и клиента.
Кроме того, следует помнить, что выбор шифра – процесс обоюдный и недаром называется согласованием. В процессе установления соединения клиент получает от сервера список поддерживаемых шифров и выбирает самый стойкий из тех, которые поддерживает сам.
Если клиент не поддерживает ни один из предложенных шифров, то соединение установить не удастся. Но и наоборот, существуют специальные атаки на понижение шифрования, цель которых согласовать старый и нестойкий шифр. Поэтому предлагаемый набор шифров — это всегда компромисс между совместимостью и безопасностью.
Так мы можем иметь «настоящий» сертификат и слабый набор шифров ради обеспечения совместимости с устаревшими клиентами или, наоборот, самоподписанный сертификат с небольшим набором самых современных криптографических алгоритмов. И вторая система будет обеспечивать гораздо более высокий уровень безопасности чем первая.
Так чем же плох самоподписанный сертификат? Тем, что с ним невозможно установить отношения доверия, которые являются ключевыми во всей современной криптографии. Проще говоря, устанавливая защищенное соединение мы хотим быть уверены, что сертификат действительно принадлежит указанному владельцу, а не третьему лицу.
Чтобы помочь нам в этом вопросе существуют центры сертификации, авторитет которых не подлежит сомнению, и, если сертификат подписан одним из этих CA, то доверие к центру сертификации распространяется на сертификат, и мы тоже можем ему доверять.
Для проверки доверия все центры сертификации выпускают собственные корневые сертификаты, которые позволяют убедиться, что сертификат выпущен именно этим издателем.
Корневые сертификаты известных издателей распространяются вместе с ОС и хранятся в особом системном хранилище, исключающем их случайную подмену.
Здесь существует один парадокс. Корневой сертификат удостоверяющего центра не является секретным, но доступ к нему в системе должен быть ограничен, так как в противном случае возможна атака типа человек посередине, и вы автоматически примете сертификат, подписанный злоумышленником.
По этой же причине требуется крайне внимательно относиться к сертификатам, которые вы устанавливаете в качестве доверенных корневых центров сертификации, так как после его установки вы будете автоматически доверять всем сертификатам, выпущенным этим центром.
Также не следует путать самозаверенные сертификаты с сертификатами частных центров сертификации, например, корпоративным CA. С последними можно легко установить доверительные отношения (если вы действительно им доверяете) просто установив в систему нужный корневой сертификат.
Самозаверенный сертификат не имеет доверенного центра сертификации в цепочке и доверительные отношения с ним установить не удастся, все, что мы можем – это добавить его в исключения, чтобы не получать уведомлений системы безопасности.
Но это нужно сделать на каждой системе, при этом обязательно проверив, тот ли это сертификат по отпечатку подписи. Но это способен сделать далеко не каждый пользователь и на практике даже добавления в исключения часто не происходит. Чаще всего предупреждение безопасности просто игнорируется, что является крайне плохой практикой, так как вам спокойно могут подменить сертификат, а вы даже не заметите.
Подведем итог: самозаверенный сертификат с точки зрения шифрования столь же безопасен, как и любой другой. Основная его проблема – это невозможность установить доверительные отношения и однозначно доверять ему без дополнительных проверок.
👍15🥱2❤1
И снова про отечественные сертификаты
Осень еще не наступила, а очередное осеннее обострение уже началось. С завидной регулярностью отдельные товарищи начинают разгонять очередную дичь про сертификаты Мицифры.
Мол какое может быть доверие этим сертификатам и этому CA если… (тут можете вписать любой набор стандартных пугалок), в отличие от коммерческих западных CA, которые прозрачны, контролируемы, регулируемы и т.д. и т.п.
Сразу начнем с того, что все взаимодействия в инфраструктуре открытых ключей (PKI) строятся на основании отношений доверия и ключевые участники этого рынка такими отношениями сильно дорожат.
Но все ли так светло и радужно? Нет, достаточно вспомнить историю с WoSign и StartCom, которые творили лютую дичь, включая выпуск сертификатов задним числом и крайне слабые проверки действительного владельца домена.
За ним последовал Symantec, тоже не последний игрок на рынке, и хотя его прегрешения были куда попроще, но это ему тоже не помогло.
Поэтому ни покровительство Минцифры, ни какие иные административные факторы не помогут отечественному CA удержать отношения доверия если он вдруг влипнет в какую-нибудь нехорошую историю.
И инициаторами вынесения вотума недоверия будет не общественность и не активисты, а крупные игроки этого рынка, пользующиеся его услугами, тот же Сбербанк.
Так что мы не видим никаких разумных предпосылок не доверять сертификатам Минцифры по различным надуманным причинам.
Но это была теория, а теперь перейдем к практике. Основная пугалка адептов секты свидетелей Товарища Майора гласит, что сразу после установки сертификата вы делаете весь свой трафик доступным тому самому Товарищу Майору.
Так ли это? Конечно же не так. Что делает удостоверяющий центр Минцифры выдавая сертификат тому же Сбербанку? Прежде всего он удостоверяется, что за сертификатом пришел именно Сбербанк и подписывает выданный сертификат своим закрытым ключом.
Теперь каждый у кого есть открытый ключ (сертификат) Минцифры может проверить подлинность этого сертификата и начать доверять ему, так как мы доверяем удостоверяющему центру, выдавшему сертификат.
Может ли теперь Минцифры расшифровать трафик, зашифрованный этим сертификатом? Нет! Сделать этот может только владелец закрытого ключа, т.е. Сбербанк. Для получения сертификата закрытый ключ удостоверяющему центру предоставлять не нужно.
Но в реальности все еще более интересно, открыв свойства защищенного соединения в браузере, например, для того же Сбербанка, мы увидим строку наподобие:
Это означает, что для формирования сеансового ключа, которым зашифрован канал связи используется алгоритм Диффи-Хеллмана, который позволяет формировать динамические ключи шифрования обоими сторонами без передачи их по каналам связи.
Сеансовые ключи являются одноразовыми и нигде не сохраняются. Это называется совершенная прямая секретность и не позволяет расшифровать записанный сеанс связи даже получив доступ к закрытому ключу владельца сертификата.
Говорить про возможный MitM тем более несерьезно, потому что такое решение должно приниматься на самом высоком уровне и для этого нужны крайне серьезные основания. Плюс не забываем о возможных негативных последствиях со стороны других крупных игроков рынка.
При том, что этот самый MitM давно уже существует на ПК многих и многих пользователей совершенно легально и с их ведома, но почему-то это никого не интересует и не создает такого ажиотажа.
Да, мы про антивирусное ПО, которое имеет функцию проверки трафика на лету, для чего устанавливает собственный доверенный сертификат и делает все тоже самое, в чем пытаются безосновательно обвинить Минцифры.
Хотя потенциальному Товарищу Майору гораздо проще пойти договориться с Касперским, чем мутить с нуля свой собственный MitM.
Поэтому – будьте благоразумны, удостоверяющий центр Минцифры ничем не отличается от любого другого удостоверяющего центра и использование его несет одинаковые с ними угрозы. При том, как мы видели выше, коммерческие УЦ тоже далеко не образцы для подражания.
Осень еще не наступила, а очередное осеннее обострение уже началось. С завидной регулярностью отдельные товарищи начинают разгонять очередную дичь про сертификаты Мицифры.
Мол какое может быть доверие этим сертификатам и этому CA если… (тут можете вписать любой набор стандартных пугалок), в отличие от коммерческих западных CA, которые прозрачны, контролируемы, регулируемы и т.д. и т.п.
Сразу начнем с того, что все взаимодействия в инфраструктуре открытых ключей (PKI) строятся на основании отношений доверия и ключевые участники этого рынка такими отношениями сильно дорожат.
Но все ли так светло и радужно? Нет, достаточно вспомнить историю с WoSign и StartCom, которые творили лютую дичь, включая выпуск сертификатов задним числом и крайне слабые проверки действительного владельца домена.
За ним последовал Symantec, тоже не последний игрок на рынке, и хотя его прегрешения были куда попроще, но это ему тоже не помогло.
Поэтому ни покровительство Минцифры, ни какие иные административные факторы не помогут отечественному CA удержать отношения доверия если он вдруг влипнет в какую-нибудь нехорошую историю.
И инициаторами вынесения вотума недоверия будет не общественность и не активисты, а крупные игроки этого рынка, пользующиеся его услугами, тот же Сбербанк.
Так что мы не видим никаких разумных предпосылок не доверять сертификатам Минцифры по различным надуманным причинам.
Но это была теория, а теперь перейдем к практике. Основная пугалка адептов секты свидетелей Товарища Майора гласит, что сразу после установки сертификата вы делаете весь свой трафик доступным тому самому Товарищу Майору.
Так ли это? Конечно же не так. Что делает удостоверяющий центр Минцифры выдавая сертификат тому же Сбербанку? Прежде всего он удостоверяется, что за сертификатом пришел именно Сбербанк и подписывает выданный сертификат своим закрытым ключом.
Теперь каждый у кого есть открытый ключ (сертификат) Минцифры может проверить подлинность этого сертификата и начать доверять ему, так как мы доверяем удостоверяющему центру, выдавшему сертификат.
Может ли теперь Минцифры расшифровать трафик, зашифрованный этим сертификатом? Нет! Сделать этот может только владелец закрытого ключа, т.е. Сбербанк. Для получения сертификата закрытый ключ удостоверяющему центру предоставлять не нужно.
Но в реальности все еще более интересно, открыв свойства защищенного соединения в браузере, например, для того же Сбербанка, мы увидим строку наподобие:
Key exchange ECDHE_RSA with P-256Это означает, что для формирования сеансового ключа, которым зашифрован канал связи используется алгоритм Диффи-Хеллмана, который позволяет формировать динамические ключи шифрования обоими сторонами без передачи их по каналам связи.
Сеансовые ключи являются одноразовыми и нигде не сохраняются. Это называется совершенная прямая секретность и не позволяет расшифровать записанный сеанс связи даже получив доступ к закрытому ключу владельца сертификата.
Говорить про возможный MitM тем более несерьезно, потому что такое решение должно приниматься на самом высоком уровне и для этого нужны крайне серьезные основания. Плюс не забываем о возможных негативных последствиях со стороны других крупных игроков рынка.
При том, что этот самый MitM давно уже существует на ПК многих и многих пользователей совершенно легально и с их ведома, но почему-то это никого не интересует и не создает такого ажиотажа.
Да, мы про антивирусное ПО, которое имеет функцию проверки трафика на лету, для чего устанавливает собственный доверенный сертификат и делает все тоже самое, в чем пытаются безосновательно обвинить Минцифры.
Хотя потенциальному Товарищу Майору гораздо проще пойти договориться с Касперским, чем мутить с нуля свой собственный MitM.
Поэтому – будьте благоразумны, удостоверяющий центр Минцифры ничем не отличается от любого другого удостоверяющего центра и использование его несет одинаковые с ними угрозы. При том, как мы видели выше, коммерческие УЦ тоже далеко не образцы для подражания.
👍30🤡15🥱4❤3🤔3