Про терминологию: в статье я сознательно использую «DevOps» в том виде, в каком эта роль часто существует на практике в небольших компаниях — как совмещение администрирования, эксплуатации и ответственности за прод.
Не хотел и не хочу «демонизировать» DevOps как культуру или профессию, а просто привел пример жизненного опыта и конкретного ожидания со стороны бизнеса. В целом как раз и пишу о том, что такое размытое понимание роли — проблема. Вот цитата "из-за непонимания DevOps-культуры, эта должность имеет более широкое понимание."
Что касается менеджмента и HR — вы правы, их фейлы здесь тоже есть, и немалые. Отсутствие чёткой модели доступа, контроля и разделения ответственности — это управленческая зона, и именно это я считаю одним из ключевых выводов из истории, пусть, возможно, в тексте это не прозвучало достаточно явно.
Про задачи — да, часть из них действительно решается начинающим админом. Но сама история не про сложность задач, а про последствия концентрации критических доступов и ответственности в одних руках без процессов и контроля.
Прочитал вашу статью и предыдущие две. Спасибо за ваш труд и желание поделиться полезной информацией. Как вариант подключение по CAN - это рабочий а главное надежный метод. Я тоже как то проводам больше доверяю, хотя это и заморочнее. Продолжайте!
У меня еще вопрос - а вы лично вот на практике какие уже IoT устройства смогли интегрировать в свою систему? Почему именно эта тематика вас заинтерисовала? У вас свой дом и вы для себя нашли практическую ценность или это больше как хобби и желание попробовать что то новое?
Ну как вариант если бы были изначально применены настройки безопасности и при регистрации нового пользователя, изменении файла cron, добавлении нового ssh ключа и подобные вещи отображались через некий телграм бот в группе где несколько человек из компании подписано. Тогда хотя бы это было сложно сделать незаметно и народ бы встрепенулся а зачем кто то делает вот это.
В первом коментарии @imbasoft специалист по ИБ, дал хороший ответ по этому вопросу.
В данной ситуации за все один человек не отвечал но у него были доступы ко всему. Его же уволили то без проблем, компания продолжала жить и продолжает.
А в целом, судя из вашего коментария, наверное, имеете ввиду что проблема не в человеке, а в системе. Хороший DevOps стоит дорого и вообще наверняка компания сама виновата.
Но суть ведь статьи не об этом. Заголовок статьи говорит о том что нужно знать о рисках работы в нашей сфере. И просьба здесь поставить себя на место "клиента" и подумать как нужно защищаться от подобного воздействия. Есть даже термин "Insider threat" и проблема на самом деле не нова. И в качестве исходящих представьте что контора реально классная и идеальная и ЗП хорошая но человек по сути своей разрушитель - выше есть коментарии о подобных личностях
Насчет целей устройства С. на работу не знаю. Конфликтов по сути никогда не было, все было в рамках приличия. Просто поняли что с человеком сложно решать вопросы и решили попращаться. Спокойно без всяких разбирательств. В полне допускаю мысль что работал еще где то так как с доступностью были проблемы, может еще чем то занимался своим. Насчет судиться, ответил чуть выше.
Да руководство собрало, как по мне, железобетонные доказательства причастности С. к данному инцеденту. На руках были логи которые четко свидетельствовали о вышеописанных манипуляциях. Обратилось в полицию. Полиция не захотела этим заниматься и дали ответ вроде "Нет состава преступления". Дальше уже никто не стал заниматься этим.
Да присоединяюсь. Тут ещё момент что вот эти все "костыли" и "Легаси" про которые пишет автор никто не смотрит. Бизнесу вообще нет дела. Им главное результат. Я написал массу кода но через лет 5 вообще перестал стараться так как из года в код клиенты от чего то отказывались что то просили обновлять. И все нужно было делать быстро. Поэтому смысла нет пыхтеть и все распихивать по полочкам если это не кому не нужно и пишешь код в одного двух человек.
Про крупные проекты там другая история. Больше про менеджмент. Но как правило вины программистов, нормальных программистов тут нет
Вот и я тоже подумал - какая то реклама пошла резко. Думал где то закончится а тут раз и завершение статьи. Это как посмотреть фильм с плохим концом, такое же послевкусие.
Типа - вообще тестировал ли я массовые рассылки? Или только поднял почтовик и радуюсь?
Да, вы безусловно правы в том, что просто поднять свой SMTP и начать массово долбить по базе – верный путь в спам и блоклисты.
В статье котрую написал я как раз больше про инфраструктуру: как поднять Hestia/Roundcube/MailWizz, настроить SPF/DKIM/DMARC/PTR, добиться базовой корректной отдачи писем и понять, где оно ломается.
Пока сценарий у моих клиентов скорее не «холодные промо по 50k адресов», а точечные письма по своей базе, где люди реально взаимодействуют с бизнесом – поэтому там история больше про правильную техническую настройку, а не про прогрев IP для масс-рассылок.
То, что я написал про «несколько человек нажмут “не спам”» – это, скорее, один из сигналов для Gmail/Яндекса, а не волшебная кнопка. Понятно, что в реальности на доставляемость ещё сильно влияют:
– репутация домена и IP (как давно живут, не светились ли в спам-репортах); – качество базы (double opt-in, отсутствие купленных/слитых адресов); – объёмы и скорость отправки (резкие всплески – красный флаг); – жалобы на спам и отписки; – содержимое писем (спам-триггеры, вёрстка, ссылки и т.п.).
В статье я сознательно не уходил глубоко в тему прогрева домена и построения репутации у почтовых сервисов, чтобы не раздувать объём. Но, судя по вашему вопросу, есть смысл сделать отдельный материал про доставляемость и «как не превратить свой сервер в генератор спама».
Если у вас есть боевой опыт массовых рассылок с собственного SMTP (что сработало / что убило репутацию) – я бы с удовольствием дополнил свою практику и статью вашими наблюдениями.
На самом деле я только настраивал систему. Письма с Roundcube уходят без проблем и ложатся как надо. А вот с MailWizz да - есть проблема потому что Google и Yandex хорошо понимает что это рассылка так как MailWizz сразу определяет себя. Но если несколько человек нажмут что это не спам - то Сервисы начнут принимать письма во входящие. Вобщем нужно раскачать рассылку
Классный пример. Практичный. Если формат выживает на графах — он переживёт почти что угодно.
Помоему тут разные читатели. Есть кто понимает а есть кто нет.
Про терминологию: в статье я сознательно использую «DevOps» в том виде, в каком эта роль часто существует на практике в небольших компаниях — как совмещение администрирования, эксплуатации и ответственности за прод.
Не хотел и не хочу «демонизировать» DevOps как культуру или профессию, а просто привел пример жизненного опыта и конкретного ожидания со стороны бизнеса. В целом как раз и пишу о том, что такое размытое понимание роли — проблема. Вот цитата "из-за непонимания DevOps-культуры, эта должность имеет более широкое понимание."
Что касается менеджмента и HR — вы правы, их фейлы здесь тоже есть, и немалые. Отсутствие чёткой модели доступа, контроля и разделения ответственности — это управленческая зона, и именно это я считаю одним из ключевых выводов из истории, пусть, возможно, в тексте это не прозвучало достаточно явно.
Про задачи — да, часть из них действительно решается начинающим админом. Но сама история не про сложность задач, а про последствия концентрации критических доступов и ответственности в одних руках без процессов и контроля.
Прочитал вашу статью и предыдущие две. Спасибо за ваш труд и желание поделиться полезной информацией. Как вариант подключение по CAN - это рабочий а главное надежный метод. Я тоже как то проводам больше доверяю, хотя это и заморочнее. Продолжайте!
У меня еще вопрос - а вы лично вот на практике какие уже IoT устройства смогли интегрировать в свою систему? Почему именно эта тематика вас заинтерисовала? У вас свой дом и вы для себя нашли практическую ценность или это больше как хобби и желание попробовать что то новое?
Ну как вариант если бы были изначально применены настройки безопасности и при регистрации нового пользователя, изменении файла cron, добавлении нового ssh ключа и подобные вещи отображались через некий телграм бот в группе где несколько человек из компании подписано. Тогда хотя бы это было сложно сделать незаметно и народ бы встрепенулся а зачем кто то делает вот это.
В первом коментарии @imbasoft специалист по ИБ, дал хороший ответ по этому вопросу.
Ну у вас и фантазия (в хорошем смысле слова). Да это частый сценарий развития событий что вы описали. У вас наверное был похожий опыт работы.
Честно вам скажу как сторонний наблюдатель - контора была в рамках приличия. Люди адекватные хорошие на редкость.
На сторону зла встать легче а вот на стороне "клиента" как бы вы поступили?
Вот здесь 100% соглашусь! Вы абсолютно правы. Это рабочий метод. Бюрократия это уже побочный эффект - но меньшее зло.
В данной ситуации за все один человек не отвечал но у него были доступы ко всему. Его же уволили то без проблем, компания продолжала жить и продолжает.
Насчет полиции ответил выше коментатору.
А в целом, судя из вашего коментария, наверное, имеете ввиду что проблема не в человеке, а в системе. Хороший DevOps стоит дорого и вообще наверняка компания сама виновата.
Но суть ведь статьи не об этом. Заголовок статьи говорит о том что нужно знать о рисках работы в нашей сфере. И просьба здесь поставить себя на место "клиента" и подумать как нужно защищаться от подобного воздействия. Есть даже термин "Insider threat" и проблема на самом деле не нова. И в качестве исходящих представьте что контора реально классная и идеальная и ЗП хорошая но человек по сути своей разрушитель - выше есть коментарии о подобных личностях
Насчет целей устройства С. на работу не знаю. Конфликтов по сути никогда не было, все было в рамках приличия. Просто поняли что с человеком сложно решать вопросы и решили попращаться. Спокойно без всяких разбирательств. В полне допускаю мысль что работал еще где то так как с доступностью были проблемы, может еще чем то занимался своим.
Насчет судиться, ответил чуть выше.
Да руководство собрало, как по мне, железобетонные доказательства причастности С. к данному инцеденту. На руках были логи которые четко свидетельствовали о вышеописанных манипуляциях. Обратилось в полицию. Полиция не захотела этим заниматься и дали ответ вроде "Нет состава преступления". Дальше уже никто не стал заниматься этим.
Да присоединяюсь. Тут ещё момент что вот эти все "костыли" и "Легаси" про которые пишет автор никто не смотрит. Бизнесу вообще нет дела. Им главное результат. Я написал массу кода но через лет 5 вообще перестал стараться так как из года в код клиенты от чего то отказывались что то просили обновлять. И все нужно было делать быстро. Поэтому смысла нет пыхтеть и все распихивать по полочкам если это не кому не нужно и пишешь код в одного двух человек.
Про крупные проекты там другая история. Больше про менеджмент. Но как правило вины программистов, нормальных программистов тут нет
Точно. Тоже самое чувствовать стал. А ещё и треки музыкальные пошли с этим ллм.ом. Все таки в творческих вещах это не уместно..
Вот и я тоже подумал - какая то реклама пошла резко. Думал где то закончится а тут раз и завершение статьи. Это как посмотреть фильм с плохим концом, такое же послевкусие.
Типа - вообще тестировал ли я массовые рассылки? Или только поднял почтовик и радуюсь?
Да, вы безусловно правы в том, что просто поднять свой SMTP и начать массово долбить по базе – верный путь в спам и блоклисты.
В статье котрую написал я как раз больше про инфраструктуру: как поднять Hestia/Roundcube/MailWizz, настроить SPF/DKIM/DMARC/PTR, добиться базовой корректной отдачи писем и понять, где оно ломается.
Пока сценарий у моих клиентов скорее не «холодные промо по 50k адресов», а точечные письма по своей базе, где люди реально взаимодействуют с бизнесом – поэтому там история больше про правильную техническую настройку, а не про прогрев IP для масс-рассылок.
То, что я написал про «несколько человек нажмут “не спам”» – это, скорее, один из сигналов для Gmail/Яндекса, а не волшебная кнопка. Понятно, что в реальности на доставляемость ещё сильно влияют:
– репутация домена и IP (как давно живут, не светились ли в спам-репортах);
– качество базы (double opt-in, отсутствие купленных/слитых адресов);
– объёмы и скорость отправки (резкие всплески – красный флаг);
– жалобы на спам и отписки;
– содержимое писем (спам-триггеры, вёрстка, ссылки и т.п.).
В статье я сознательно не уходил глубоко в тему прогрева домена и построения репутации у почтовых сервисов, чтобы не раздувать объём. Но, судя по вашему вопросу, есть смысл сделать отдельный материал про доставляемость и «как не превратить свой сервер в генератор спама».
Если у вас есть боевой опыт массовых рассылок с собственного SMTP (что сработало / что убило репутацию) – я бы с удовольствием дополнил свою практику и статью вашими наблюдениями.
Спасибо за честный отзыв. Плюсану!
Да мои клиенты арендовали у DicitalOcean - у них проблем с портами не возникло. Но заметка очень кстати. Надо бы проверять такие вещи. Спасибо.
На самом деле я только настраивал систему. Письма с Roundcube уходят без проблем и ложатся как надо. А вот с MailWizz да - есть проблема потому что Google и Yandex хорошо понимает что это рассылка так как MailWizz сразу определяет себя. Но если несколько человек нажмут что это не спам - то Сервисы начнут принимать письма во входящие. Вобщем нужно раскачать рассылку
Полностью согласен с автором. Прочитал как будто книгу "Вредные советы" от Остера для детей. Был похожий опыт, что описал автор, к счастью не долго.