Вот кстати да, натолкнули на мысль. Такая огромная потребность есть в адекватной бирже. Fl и по дизайну не очень, все глючит периодически. Не адекватная денежная политика. Бизразличие ко всем, лишь бы деньги срубать. Тем самым отталкивает серьёзных людей. Почему Яндекс Сбер или кто то такой не могут организовать нормальной площадки?
Не совсем понимаю где в тексте есть слова из которых можно сделать вывод что "статья для раскрутки"?
Я писал тут о моей жизни фрилансера и мне пришлось указать название биржи так как за все биржи сказать не могу и было бы не справедливо на мой взгляд всех под одну гребенку.
И в целом по моему получилось больше "антиреклама".
Насчёт их денежной политики полностью солидарен с вами. Реально раздражает и мне кажется это вызовет отток исполнителей ещё больше.
Реально дали настроение. Спасибо большое за ваш коментарий - я думал на Хабре только одни инженеры читают, кажется что не только! Значит все намного проще чем я думал. Спасибо за хороший настрой и дельные советы
Про терминологию: в статье я сознательно использую «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 (что сработало / что убило репутацию) – я бы с удовольствием дополнил свою практику и статью вашими наблюдениями.
Здесь в статье всего 3 ссылки.
1 - на хабр. Человек сделал перевод как распаковать любую профессию
2 - на hh что бы не перепечатывать определения кто такой фрилансер. Не хотел усложнять текст. Этот сайт я думаю в рекламе не нуждается
3 - сам fl. Который если ставишь точку ру то автоматом является ссылкой
Разве это значит "обильно снабжены ссылками"?
С кворком к сожалению не знаком, но тут есть человек кто дал комментарии и про кворк и он в принципе говорит что таже ситуация
Вот кстати да, натолкнули на мысль. Такая огромная потребность есть в адекватной бирже. Fl и по дизайну не очень, все глючит периодически. Не адекватная денежная политика. Бизразличие ко всем, лишь бы деньги срубать. Тем самым отталкивает серьёзных людей. Почему Яндекс Сбер или кто то такой не могут организовать нормальной площадки?
Не совсем понимаю где в тексте есть слова из которых можно сделать вывод что "статья для раскрутки"?
Я писал тут о моей жизни фрилансера и мне пришлось указать название биржи так как за все биржи сказать не могу и было бы не справедливо на мой взгляд всех под одну гребенку.
И в целом по моему получилось больше "антиреклама".
Насчёт их денежной политики полностью солидарен с вами. Реально раздражает и мне кажется это вызовет отток исполнителей ещё больше.
Реально дали настроение. Спасибо большое за ваш коментарий - я думал на Хабре только одни инженеры читают, кажется что не только! Значит все намного проще чем я думал. Спасибо за хороший настрой и дельные советы
Классный пример. Практичный. Если формат выживает на графах — он переживёт почти что угодно.
Помоему тут разные читатели. Есть кто понимает а есть кто нет.
Про терминологию: в статье я сознательно использую «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 (что сработало / что убило репутацию) – я бы с удовольствием дополнил свою практику и статью вашими наблюдениями.
Спасибо за честный отзыв. Плюсану!