Комментарии 52
По-дилетантски предположу, что вместо изобретения велосипеда можно было ежедневно создавать разностные резервные копии (differential backup). Что касается файлов электронных писем, содержащих вложения, для их упаковки можно было использовать бесплатный архиватор 7-Zip со сторонним плагином eDecoder.
Если я в чем-то ошибаюсь, прошу поправить.
P.S. Кстати, есть еще бесплатный архиватор ZPAQ, который тоже может подойти для означенных целей.
Также плагин содержит специальный кодек eSplitter, добавляющий в 7-Zip возможность более эффективной упаковки в формат 7z текстовых файлов, содержащих в себе данные, упакованные методом base64 и некоторыми другими методами кодирования двоичных файлов в текстовые. Примерами таких текстовых файлов могут служить, например, сохраненные копии web страниц в формат MTHML, электронные письма в формате EML, почтовые базы в форматах MBOX и TBB, электронные книги с изображениями в формате FB2, и множество других.
<...>
Использование кодека eSplitter
Принцип сжатия
При упаковке кодек eSplitter ищет в текстовом файле закодированные двоичные данные и разделяет файл на две части. В первую часть передаются текстовые данные, а во вторую декодированные двоичные данные. Это два совершенно разных типа данных, и весьма разумно для их сжатия применять два независимых метода сжатия.
Кодек знает о внутренней структуре некоторых форматов файлов (EML, MHTML, MBOX, TBB, WARC), благодаря чему сжатие этих форматов производится наиболее оптимально.
Если я в чем-то ошибаюсь, прошу поправить.
P.S. Кстати, есть еще бесплатный архиватор ZPAQ, который тоже может подойти для означенных целей.
Недавно пролетало про софт для бэкапов BORG, где встроена дедупликация.
https://habr.com/company/flant/blog/420055/
Так же можно поделить на 2 категории — новые письма и старые.
Раскидать по каталогам по годам, активно бэкапить только текущий год, остальные проверять на изменения и не трогать, если есть копия.
А еще весёлый факт расскажу — у меня смежная задача — анализировать почту на предмет нужных вложений с четкими названиями. Как выяснилось, иногда справляются с задачей вставив картинку в html тело письма (gmail таким грешит), бывает mime вложенное в mime вложенное в mime.
Так же можно поделить на 2 категории — новые письма и старые.
Раскидать по каталогам по годам, активно бэкапить только текущий год, остальные проверять на изменения и не трогать, если есть копия.
Давным-давно, когда жесткие диски были медленные, я вынужденно применял именно этот подход к своей скромной почтовой базе. Для обработки только нужных каталогов использовал связку nnCron + nnBackup. К сожалению, не могу больше рекомендовать этот софт, поскольку не уверен в том, что с ним не возникнет проблем на новых ОС (привет Windows 10).
BORG – интересный проект, спасибо.
На хабре еще было некое коммерческое решение с похожим функционалом. Цена расстроила.
Минус таких проектов (для меня, по крайней мере): «свой формат». По сути, тоже костыли, только больше (и, следовательно, больше поле для поломок). Проблема-то, в общем, а) в формате б) в организованности пользователей.
А что касается раскидывания – в моём сервере только две опции: «бэкапить» и «не бэкапить» :(
На хабре еще было некое коммерческое решение с похожим функционалом. Цена расстроила.
Минус таких проектов (для меня, по крайней мере): «свой формат». По сути, тоже костыли, только больше (и, следовательно, больше поле для поломок). Проблема-то, в общем, а) в формате б) в организованности пользователей.
А что касается раскидывания – в моём сервере только две опции: «бэкапить» и «не бэкапить» :(
Как решается проблема с безопасностью доступа к файлам? Условно — если раньше файл был в письме, то он доступен только адресату и отправителю (ну, и всем промежуточным узлам). Теперь — можно ходить по ссылкам на аттачменты всем
На усмотрение разворачивающего инфраструктуру.
Я положил файлы в папки на сетевое хранилище с доступом только на чтение и только пользователю, чей ящик, и соответственно права на ftp.
Я положил файлы в папки на сетевое хранилище с доступом только на чтение и только пользователю, чей ящик, и соответственно права на ftp.
обработке подвергается ТОЛЬКО входящая почта? Т.е. в исходящей никаких оптимизаций?
Нет, для Sent папок ровно то же, что и для входящих.
На вход любые eml можно подать, утилите без разницы.
На вход любые eml можно подать, утилите без разницы.
1. Квоты (1-2 гигабайта, випам побольше с сетевым архивом), иначе почта мгновенно превращается в аналог файлопомойки.
2. Выгрузка почты старше пары месяцев в локальный архив на ПК пользователя.
3. Инкрементное резервное копирование. Полные копии на выходных.
4. Обслуживание и оптимизация почтовой базы раз в квартал.
5. Выгрузка в архив ящиков пользователей покинувших организацию с последующим удалением из базы.
6. Бэкап с поддержкой application aware. Восстановление от виртуалки в целом, до вложения из письма.
Виртуализация, СРК и хранилище с поддержкой дедупликации, мониторинг, варнинги если что идет не так — само собой разумеющиеся вещи.
2. Выгрузка почты старше пары месяцев в локальный архив на ПК пользователя.
3. Инкрементное резервное копирование. Полные копии на выходных.
4. Обслуживание и оптимизация почтовой базы раз в квартал.
5. Выгрузка в архив ящиков пользователей покинувших организацию с последующим удалением из базы.
6. Бэкап с поддержкой application aware. Восстановление от виртуалки в целом, до вложения из письма.
Виртуализация, СРК и хранилище с поддержкой дедупликации, мониторинг, варнинги если что идет не так — само собой разумеющиеся вещи.
Всё это бесспорно.
Однако корень проблемы и причина этого длинного списка ресурсоёмких задач со сложными связями – по моему мнению, в старом и кривом стандарте. Письмо – это текст, а не интерактивная вебдваноль страница и не файловое хранилище. Можно бесконечно дедуплицировать, инкрементировать, обслуживать и так далее, пока хватает мощностей. Но насколько это на самом деле оптимальный путь? Может быть, пока спрямить?
Однако корень проблемы и причина этого длинного списка ресурсоёмких задач со сложными связями – по моему мнению, в старом и кривом стандарте. Письмо – это текст, а не интерактивная вебдваноль страница и не файловое хранилище. Можно бесконечно дедуплицировать, инкрементировать, обслуживать и так далее, пока хватает мощностей. Но насколько это на самом деле оптимальный путь? Может быть, пока спрямить?
гугл и яндекс автоматически конвертируют большие файлы в ссылку на файл в гуглодиск или яндексдиск.
Я понимаю Ваш энтузиазм и внутреннюю гордость от реализации решения.
У меня 10к-12к это просто среднее число писем за сутки прошедшее через транспортный сервер в рабочие дни. Ты либо делаешь по правильному, либо оно не бэкапится.
У меня 10к-12к это просто среднее число писем за сутки прошедшее через транспортный сервер в рабочие дни. Ты либо делаешь по правильному, либо оно не бэкапится.
10к-12к среднее число писем за сутки
А это со спамом или чистыми?
либо делаешь по правильному, либо оно не бэкапится
Опять же, сложно спорить. Объёмы сейчас гигантские. Но, как я упомянул в статье, «добавить мощности» для меня был не вариант. А в процессе реализации этого решения мне подумалось, что найденный путь проще и экономит множество ресурсов как вычислительных, так и человеческих и организационных. Процессор-часы, например, можно потратить на Folding@home, а не на сортировку никому не нужных, забытых котиков.
Мы привыкли, что у нас в письмах лежит всё что угодно, но насколько это оправдано?
Чистыми, таки за спам пограничные решения отвечают.
Да и ресурсы, не Ваши, а принадлежат организации. Как и Ваше рабочее время.
Если руководство прямо говорит что, нужно свободные ресурсы направлять на Folding@home, то все вроде норм. Иначе Ваша инициатива ничем не отличается от майнинга на себя, поскольку работающему оборудованию и счетам за электричество всеравно какими намерениями Вы руководствовались.
Содержимое писем, акромя проверки на спам, процессов в рамках DLP и того что в Вашем ящике нисколь Вас не должно интересовать. Котики, бизнес информация или ежедневная рассылка интимных прелестей — это информация тех кто участвует в двухстороннем обмене, она не Ваша.
Если есть проблемы с ресурсами: озвучьте их руководству, приходите сразу с готовыми решениями: добавить диски, ограничить ящики и пользователей
Принесите статистику: топ 10-20-50-100 ящиков по размеру, топ 10-20-50-100 получателей почты, как быстро растет база. Прогноз, когда все это встанет колом, если ничего не сделать.
По резервному копированию тоже самое: Текущее состояние, сколько времени понадобится что бы сервер после полного падения опять начал получать и отправлять почту, сколько времени до момента когда пользователи получат доступ к своим ящикам и почте в ней. Наглядную картинку в RTO/RPO.
Затем предложения: Столько денег — такие то RTO/RPO, такая то глубина архива, а за такое количество денег — такие то фишечки в довесок, которые снижают RTO в разы.
Пускай они примут решение и несут ответственность. Ваша задача объяснить риски, их на основе рискменеджмента принять решение.
И помните, пока вы тут колхозите, драугр качается.
Да и ресурсы, не Ваши, а принадлежат организации. Как и Ваше рабочее время.
Если руководство прямо говорит что, нужно свободные ресурсы направлять на Folding@home, то все вроде норм. Иначе Ваша инициатива ничем не отличается от майнинга на себя, поскольку работающему оборудованию и счетам за электричество всеравно какими намерениями Вы руководствовались.
Содержимое писем, акромя проверки на спам, процессов в рамках DLP и того что в Вашем ящике нисколь Вас не должно интересовать. Котики, бизнес информация или ежедневная рассылка интимных прелестей — это информация тех кто участвует в двухстороннем обмене, она не Ваша.
Если есть проблемы с ресурсами: озвучьте их руководству, приходите сразу с готовыми решениями: добавить диски, ограничить ящики и пользователей
Принесите статистику: топ 10-20-50-100 ящиков по размеру, топ 10-20-50-100 получателей почты, как быстро растет база. Прогноз, когда все это встанет колом, если ничего не сделать.
По резервному копированию тоже самое: Текущее состояние, сколько времени понадобится что бы сервер после полного падения опять начал получать и отправлять почту, сколько времени до момента когда пользователи получат доступ к своим ящикам и почте в ней. Наглядную картинку в RTO/RPO.
Затем предложения: Столько денег — такие то RTO/RPO, такая то глубина архива, а за такое количество денег — такие то фишечки в довесок, которые снижают RTO в разы.
Пускай они примут решение и несут ответственность. Ваша задача объяснить риски, их на основе рискменеджмента принять решение.
И помните, пока вы тут колхозите, драугр качается.
Вы, вероятно, никогда не работали в не-ИТ конторах. Кратко суть такова: руководство не интересуют технические детали, оно не хочет вникать в возможные решения, и из вариантов, требующих вложения денег или вложения времени администратора, оно всегда выберет вложение времени: оно всё равно уже оплачено. «Делай как хочешь, но чтобы всё работало и пользователи не жаловались». Такие вот простые и понятные KPI.
По сути проблемы: решение с выдёргиванием вложений имеет право быть, но когда исчерпаны другие, более простые и безопасные решения: расширение хранилища, инкрементный/дифференциальный бекап, многопоточный бекап, переезд хранилища в БД.
Решение — яркий пример того, что менеджмента в области ИТ в компании не существует. Сам так долго работал, теперь мучительно избавляюсь от приобретённых вредных привычек.
По сути проблемы: решение с выдёргиванием вложений имеет право быть, но когда исчерпаны другие, более простые и безопасные решения: расширение хранилища, инкрементный/дифференциальный бекап, многопоточный бекап, переезд хранилища в БД.
Решение — яркий пример того, что менеджмента в области ИТ в компании не существует. Сам так долго работал, теперь мучительно избавляюсь от приобретённых вредных привычек.
Если компания — не-ИТ, то вполне логично отдать ИТ на сторону. Так дешевле.
Вариант, когда это не работает, когда ты очень большой (ГазПром?), но там может быть внутренний аутсорс.
Вариант, когда это не работает, когда ты очень большой (ГазПром?), но там может быть внутренний аутсорс.
Отчего ж не работал. Я и в колледже успел поработать, и в ФГУПах разных, и на корп как сейчас.
Вы просто пытаетесь помочь и спасти чужой бизнес за счет себя самого. Ну окей, жертвуйте собой за «Большое спасибо». Если организации удобно оплачивать Ваши ночные работы и ждать, когда Вы все почините, а в коллективе Вас будут восхвалять как героя и Вам это будет нравиться, это прекрасно. Однако годы идут, а писец который случится в ночь за день до вашей давно запланированной поездки в далекую и солнечную страну поставит Вас перед выбором: про$рать отдых, потому что Вам нужно пару дней (там все медленно и сложно, и только Вы знаете где какой нужный скрипт лежит) на оживление всего и остаться героем в коллективе за «Большое спасибо!», или отдохнуть с чувством тревоги и выключенным телефоном, и вернуться в переполненный серной кислотой коллектив, который лишился из-за Вас премий в этом месяце/квартале, или проекта, который мог кормить контору ближайшие полгода.
Вы проиграете, это просто вопрос времени.
Зыю
«Большое спасибо» в рот своему голодному ребенку не положишь.
Вы просто пытаетесь помочь и спасти чужой бизнес за счет себя самого. Ну окей, жертвуйте собой за «Большое спасибо». Если организации удобно оплачивать Ваши ночные работы и ждать, когда Вы все почините, а в коллективе Вас будут восхвалять как героя и Вам это будет нравиться, это прекрасно. Однако годы идут, а писец который случится в ночь за день до вашей давно запланированной поездки в далекую и солнечную страну поставит Вас перед выбором: про$рать отдых, потому что Вам нужно пару дней (там все медленно и сложно, и только Вы знаете где какой нужный скрипт лежит) на оживление всего и остаться героем в коллективе за «Большое спасибо!», или отдохнуть с чувством тревоги и выключенным телефоном, и вернуться в переполненный серной кислотой коллектив, который лишился из-за Вас премий в этом месяце/квартале, или проекта, который мог кормить контору ближайшие полгода.
Вы проиграете, это просто вопрос времени.
Зыю
«Большое спасибо» в рот своему голодному ребенку не положишь.
Всё так.
Расскажите, каковы критерии вредности привычек.
Расскажите, каковы критерии вредности привычек.
1. Отсутствие обсуждения решений с другими сотрудниками ИТ-отдела, если таковые существуют. Обсуждать желательно даже то, что к компетенции других сотрудников не относится: даже в этом случае взгляд со стороны позволяет выявить слабые стороны решения.
2. Замена тупых, надёжных, проверенных стандартных решений велосипедами. Я прекрасно понимаю, что хочется сделать своё решение (сам ловлю кайф от велосипедописания), но нужно ударить себя по рукам и найти поддерживаемое широким сообществом или коммерческой компанией решение. Почти всё уже написано до нас, и лучше потратить месяц на поиски и тесты, чем потом полгода на допиливание и самостоятельную поддержку велосипеда. Время администратора почти всегда дороже стоимости софта и железа с поддержкой, если посчитать TCO. Поэтому нужно считать и показывать цифры руководству.
3. Отсутствие системного подхода к обеспечению функционирования и развития ИТ-систем. Это, на самом деле, задача руководителя. Но если такового с нужными навыками нет, то хинт — заочный курс ИТ-менеджмента от ВШЭ стоит совсем недорого (меньше $2k пару лет назад). ITSM в виде COBIT/ITIL, методологии менеджмента ИТ-проектов — всё это офигительно важно в стратегическом плане. Туда же — документирование и процессы, это всё уже продумано в ITSM.
Но! Если в компании три человека и перспективы неясны, то это особого смысла не имеет. В ситуации стартапа имеет смысл делать ad hoc и думать об архитектуре и процессах позже, когда взлетело. В случае же более-менее устойчивого и развивающегося бизнеса это важно с самого начала.
2. Замена тупых, надёжных, проверенных стандартных решений велосипедами. Я прекрасно понимаю, что хочется сделать своё решение (сам ловлю кайф от велосипедописания), но нужно ударить себя по рукам и найти поддерживаемое широким сообществом или коммерческой компанией решение. Почти всё уже написано до нас, и лучше потратить месяц на поиски и тесты, чем потом полгода на допиливание и самостоятельную поддержку велосипеда. Время администратора почти всегда дороже стоимости софта и железа с поддержкой, если посчитать TCO. Поэтому нужно считать и показывать цифры руководству.
3. Отсутствие системного подхода к обеспечению функционирования и развития ИТ-систем. Это, на самом деле, задача руководителя. Но если такового с нужными навыками нет, то хинт — заочный курс ИТ-менеджмента от ВШЭ стоит совсем недорого (меньше $2k пару лет назад). ITSM в виде COBIT/ITIL, методологии менеджмента ИТ-проектов — всё это офигительно важно в стратегическом плане. Туда же — документирование и процессы, это всё уже продумано в ITSM.
Но! Если в компании три человека и перспективы неясны, то это особого смысла не имеет. В ситуации стартапа имеет смысл делать ad hoc и думать об архитектуре и процессах позже, когда взлетело. В случае же более-менее устойчивого и развивающегося бизнеса это важно с самого начала.
Спасибо за развёрнутый ответ!
Хотя противоречия не увидел. В статье нигде не указано, что это «единственное», «лучшее» и тп. решение, равно как и нет призыва всегда и всюду велосипедить.
Ну а совсем без велосипедов скучно. Да и откуда бы ещё взяться новым идеям, как не из экспериментов. Вы согласны?
Хотя противоречия не увидел. В статье нигде не указано, что это «единственное», «лучшее» и тп. решение, равно как и нет призыва всегда и всюду велосипедить.
Ну а совсем без велосипедов скучно. Да и откуда бы ещё взяться новым идеям, как не из экспериментов. Вы согласны?
По поводу пункта 1 — вероятно верно.
По поводу пункта 2 — ну вы же сами признались "сам ловлю кайф от велосипедописания" вот и ловите, и других нечего отговаривать, а вот так
Почти всё уже написано до нас, и лучше потратить месяц на поиски и тесты, чем потом полгода на допиливание и самостоятельную поддержку велосипеда
будет как минимум неинтересно (и это главное), а с большой вероятностью ещё и плохого качества (да, все эти "готовые решения" зачастую подходят лишь частично, содержат баги и прочие проблемы)
Поэтому нужно считать и показывать цифры руководству.
Ввиду указанных выше причин вы ничего достоверно не посчитаете, не попробовав. А после "попробовав" уже поздно считать.
1. Категорически не согласен. Бесплатные почтовики уже предлагают десятки ГиБ свободного пространства.
У нас в компании проблема решается проще. Есть два типа пользователей: с ящиками 1ГиБ и 5ГиБ с разной стоимостью (ага!). И дурацким ограничением на размер аттачмента в 10МиБ. Не скажу, что это идеально, но вроде работает.
Что мешает сделать бездонный (относительно) ящик?
2. Сомнительно.
В остальном согласен.
У нас в компании проблема решается проще. Есть два типа пользователей: с ящиками 1ГиБ и 5ГиБ с разной стоимостью (ага!). И дурацким ограничением на размер аттачмента в 10МиБ. Не скажу, что это идеально, но вроде работает.
Что мешает сделать бездонный (относительно) ящик?
2. Сомнительно.
В остальном согласен.
1. Ой. Покажите мне бесплатный почтовик, который проглотит хотя бы больше 500 пользователей и даст возможность автоматизации в управлении жизненным циклом учетных записей. И не будет банить ВСЕ учетки в почтовом домене, потому что «наши алгоритмы зафиксировали подозрительную активность» каждые три дня.
Бездонные ящики на вполне конечных стороджах не бывают.
2. А куда Вы деваете почту когда у сотрудника ящик забивается? Меняете сотрудника?
Бездонные ящики на вполне конечных стороджах не бывают.
2. А куда Вы деваете почту когда у сотрудника ящик забивается? Меняете сотрудника?
1. Любой корпоративный тариф у GMail или Outlook 365 скорее всего будет стоить денег. Но все равно несравнимых со стоимостью поддержки своего почтового сервера (стандартная дилемма CAPEX/OPEX). Яндекс вроде как бесплатен совсем, но прямо скажу, что его интерфейс действительно не очень удобен. Касательно «подозрительной активности». Никто, повторяю — никто не сравнится со спам фильтрами в гмайле и яндексе. Был опыт использование kaspersky antispam (бонусом антивирус или наоборот), но он просто адово дорогой + у него процент срабатывания несущественно, но хуже.
> Бездонные ящики на вполне конечных стороджах не бывают.
согласен, что чудес не бывает.
2. Ну, если он уперся в 5 ГиБ, то это его персональные проблемы. На текущий момент это достаточно разумная квота (но 10 ГиБ лучше)))) Архив на локальном устройстве не решает проблему мобильности пользователя: у него может быть и ноутбук, и планшет, и телефон. И все с настроенной корп. почтой.
> Бездонные ящики на вполне конечных стороджах не бывают.
согласен, что чудес не бывает.
2. Ну, если он уперся в 5 ГиБ, то это его персональные проблемы. На текущий момент это достаточно разумная квота (но 10 ГиБ лучше)))) Архив на локальном устройстве не решает проблему мобильности пользователя: у него может быть и ноутбук, и планшет, и телефон. И все с настроенной корп. почтой.
При 10-20 пользователях да. Несравнимо.
Возьмем 300.
Самый дешманский Office 365 бизнес базовый с Exchange в месяц будет стоить 112 500, или 1 125 000 рублей если сразу брать год. Ящик 50 гигов, облачный диск 1 террабайт. Все на одного пользователя.
Берем гугл. цены там без НДС и в баксах, $ прямо сейчас он стоит 66.88.
в месяц будет стоить 118 377,6, или 1 183 776 рублей если сразу брать год. Почта безлимит, облачный диск 30 гигов на пользователя.
Итого видим, что меньше 1.1 миллиона не выходит, но цены растут, так что 1.2 можно смело закладывать.
Админ у нас уже есть, его не может не быть на контору из 300 сотрудников. И без разницы, что он будет админить, облако или онпремайз. Если он нормальный админ конечно.
Можно ли обеспечить почтовую инфраструктуру в разрезе пяти лет включая железо с дублированием и решением для резервного копирования + лицензии на софт? Легко. И выйдет дешевле.
Гибкость под потребности организации в разы выше. Скорость реакции выше. Автоматизация и интеграция с внутренними ресурсами легче и проще.
Контроль своей инфраструктуры — да.
Возьмем 300.
Самый дешманский Office 365 бизнес базовый с Exchange в месяц будет стоить 112 500, или 1 125 000 рублей если сразу брать год. Ящик 50 гигов, облачный диск 1 террабайт. Все на одного пользователя.
Берем гугл. цены там без НДС и в баксах, $ прямо сейчас он стоит 66.88.
в месяц будет стоить 118 377,6, или 1 183 776 рублей если сразу брать год. Почта безлимит, облачный диск 30 гигов на пользователя.
Итого видим, что меньше 1.1 миллиона не выходит, но цены растут, так что 1.2 можно смело закладывать.
Админ у нас уже есть, его не может не быть на контору из 300 сотрудников. И без разницы, что он будет админить, облако или онпремайз. Если он нормальный админ конечно.
Можно ли обеспечить почтовую инфраструктуру в разрезе пяти лет включая железо с дублированием и решением для резервного копирования + лицензии на софт? Легко. И выйдет дешевле.
Гибкость под потребности организации в разы выше. Скорость реакции выше. Автоматизация и интеграция с внутренними ресурсами легче и проще.
Контроль своей инфраструктуры — да.
Расчет сложный получается.
Если забиваться на MS Exchange, то это стоимость почтового сервера + лицензии на пользователей. Для крупных компаний это скорее всего как минимум две лицензии на Exchange Server 2016 Enterprise (для отказоустойчивости) + лицензии на БД (MSSQL?) + User CAL Standard + User CAL Enterprise. Релизный цикл ПО такого класса у M$ примерно 3 года. Потом вроде как нужно апгрейдиться (хотя секьюрити патчи выходят — поэтому теоретически — можно сидеть хоть на Экчендж 2010). Помимо прочего — нужна лицензия на ОС, дополнительные средства ПО (антивирус? что-то типа ISA? и пошло-поехало). Поэтому сумма млн 5. руб в разрезе TCO 3 года кажутся вполне нормальными для организации в 300 человек при условии, что делаем свой почтовик в периметре.
Вы сами показали, что облачный сервис выходит в 1.2 млн руб. в год.
Я абсолютно уверен, что разница в суммах между своей почтой и почтой в облаке не будет на порядки. Может в разы — для каждого конкретного случая с перевесом в одну из сторон.
Что мы имеем в минусах с облаком?
1. Контроль своей инфраструктуры — да
2. Сложности с интеграцией со всякими скриптами и пр. — да
3. Невозможность настроить некоторые вещи (типа спам-фильтров) — да, хотя неясно нужно ли это
Вопрос с маркетинговыми рассылками открыт. Если их рассылать самостоятельно со своего почтовика, есть шанс залететь в черный список, а потом и легитимная почта не будет ходить. Что делать? Есть куча сервисов типа sendgrid, Mailchimp и пр., но они прям недешевые.
Если забиваться на MS Exchange, то это стоимость почтового сервера + лицензии на пользователей. Для крупных компаний это скорее всего как минимум две лицензии на Exchange Server 2016 Enterprise (для отказоустойчивости) + лицензии на БД (MSSQL?) + User CAL Standard + User CAL Enterprise. Релизный цикл ПО такого класса у M$ примерно 3 года. Потом вроде как нужно апгрейдиться (хотя секьюрити патчи выходят — поэтому теоретически — можно сидеть хоть на Экчендж 2010). Помимо прочего — нужна лицензия на ОС, дополнительные средства ПО (антивирус? что-то типа ISA? и пошло-поехало). Поэтому сумма млн 5. руб в разрезе TCO 3 года кажутся вполне нормальными для организации в 300 человек при условии, что делаем свой почтовик в периметре.
Вы сами показали, что облачный сервис выходит в 1.2 млн руб. в год.
Я абсолютно уверен, что разница в суммах между своей почтой и почтой в облаке не будет на порядки. Может в разы — для каждого конкретного случая с перевесом в одну из сторон.
Что мы имеем в минусах с облаком?
1. Контроль своей инфраструктуры — да
2. Сложности с интеграцией со всякими скриптами и пр. — да
3. Невозможность настроить некоторые вещи (типа спам-фильтров) — да, хотя неясно нужно ли это
Вопрос с маркетинговыми рассылками открыт. Если их рассылать самостоятельно со своего почтовика, есть шанс залететь в черный список, а потом и легитимная почта не будет ходить. Что делать? Есть куча сервисов типа sendgrid, Mailchimp и пр., но они прям недешевые.
Три. Транспорт, и два держателя мэйлбоксов для поддержки DAG. MSSQL включен в стоимость изначально. Возможностей Standard редакции вполне хватает. Одну мажорную версию вполне можно пропустить, поскольку тот же 2010 вполне сосуществует с 2016 и позволяет напрямую мигрировать ящики в старшую версию. Итого 5-7 лет использования купленной чанги вполне реально без ущерба безопасности и функционала.
Считается, да, сложно. Всегда индивидуально. Всегда нужно считать экономику и использовать рискменеджмент. Никто не запрещает использовать гибрид, и для мелких организаций, до 200-300 сотрудников, почта в облаке это реальный выход на текущий момент. Но и это будет не бесплатно, это нужно понимать. И всеравно нужен человек, который будет понимать что делать с этим облаком и разбираться с его особенностями.
У мэйла и яндекса, сейчас почту взять дешевле. За яндекс не скажу, но мэйл бизнес вполне стабилен, если ты на платном тарифе.
Считается, да, сложно. Всегда индивидуально. Всегда нужно считать экономику и использовать рискменеджмент. Никто не запрещает использовать гибрид, и для мелких организаций, до 200-300 сотрудников, почта в облаке это реальный выход на текущий момент. Но и это будет не бесплатно, это нужно понимать. И всеравно нужен человек, который будет понимать что делать с этим облаком и разбираться с его особенностями.
У мэйла и яндекса, сейчас почту взять дешевле. За яндекс не скажу, но мэйл бизнес вполне стабилен, если ты на платном тарифе.
НЛО прилетело и опубликовало эту надпись здесь
Да, это я не записал, врать не буду.
Могу только сказать, что минимум пять ящиков с квотой 4 Гб, раньше забитые под завязку, теперь спокойно умещаются в 1 Гб каждый.
Могу только сказать, что минимум пять ящиков с квотой 4 Гб, раньше забитые под завязку, теперь спокойно умещаются в 1 Гб каждый.
По результатам очередной обработки:
1115 элементов общим объёмом 1,25 Гб,
превращаются в 1115 элементов общим объёмом 30 Мб,
извлечено 890 файлов общим объёмом 900 Мб в файловое хранилище,
среди них к 8 файлам найдены идентичные и заменены ссылкой на единый оригинал.
1115 элементов общим объёмом 1,25 Гб,
превращаются в 1115 элементов общим объёмом 30 Мб,
извлечено 890 файлов общим объёмом 900 Мб в файловое хранилище,
среди них к 8 файлам найдены идентичные и заменены ссылкой на единый оригинал.
> Apple mail not supported. По мне – и Будда с ним;
Они в итоге обрабатываются-то хотя бы? Потому что если нет — вас однажды обязательно ждет увлекательная беседа с начальством «ПАЧИМУМЫНЕПОЛУЧИЛИПИСЬМООТВАЖНОГОКЛИЕНТА???!!!!»
> Бьются письма со сложным форматированием. Обычно это флаеры с Букинга или реклама;
О как. Тогда я таки советую заранее сочинить увлекательную отмазку для начальства на вышеописанный случай. Подсказка — технические детали насчет бэкапа его не убедят, инфа 146%.
> Таким вот тернистым путём задача была решена.
Это, увы, не задача решена. Это был сделан временный костыль, который вам однажды аукнется. По закону подлости однажды или грохнется нужное письмо или там понадобится письмо _именно_то_которое_пришло_от_отправителя_ и вы как автор этой системы окажетесь крайним.
С котиками и семейными альбомами в почте надо бороться только административно, подкладывая подписанную шефом бумажку под каждое решение. А постфактум, под капотом какие-то действия с почтой делать — моветон и игра с огнем.
А проблемы с объемом и скоростью бэкапа лучше все-таки забивать железом.
Они в итоге обрабатываются-то хотя бы? Потому что если нет — вас однажды обязательно ждет увлекательная беседа с начальством «ПАЧИМУМЫНЕПОЛУЧИЛИПИСЬМООТВАЖНОГОКЛИЕНТА???!!!!»
> Бьются письма со сложным форматированием. Обычно это флаеры с Букинга или реклама;
О как. Тогда я таки советую заранее сочинить увлекательную отмазку для начальства на вышеописанный случай. Подсказка — технические детали насчет бэкапа его не убедят, инфа 146%.
> Таким вот тернистым путём задача была решена.
Это, увы, не задача решена. Это был сделан временный костыль, который вам однажды аукнется. По закону подлости однажды или грохнется нужное письмо или там понадобится письмо _именно_то_которое_пришло_от_отправителя_ и вы как автор этой системы окажетесь крайним.
С котиками и семейными альбомами в почте надо бороться только административно, подкладывая подписанную шефом бумажку под каждое решение. А постфактум, под капотом какие-то действия с почтой делать — моветон и игра с огнем.
А проблемы с объемом и скоростью бэкапа лучше все-таки забивать железом.
Спасибо за мнение!
Они остаются в неизменном виде. Никакого криминала.
Вот в этом минус сугубо технического подхода.
Письма старше года на самом деле никто не читает и не использует. Просто «нам так спокойнее».
Видимо, я не совсем корректно сформулировал общую мысль.
Apple mail not supported.
Они в итоге обрабатываются-то хотя бы?
Они остаются в неизменном виде. Никакого криминала.
Бьются письма со сложным форматированием. Обычно это флаеры с Букинга или реклама;
О как. Тогда я таки советую заранее сочинить увлекательную отмазку для начальства
Вот в этом минус сугубо технического подхода.
Письма старше года на самом деле никто не читает и не использует. Просто «нам так спокойнее».
С котиками и семейными альбомами в почте надо бороться только административно, подкладывая подписанную шефом бумажку под каждое решение. А постфактум, под капотом какие-то действия с почтой делать — моветон и игра с огнем.
Видимо, я не совсем корректно сформулировал общую мысль.
Когда у меня в очередной раз сбойнул почтовый сервер, я тупо потратил день и переметнулся на Гугл Почту. Больше всего времени понадобилось на изучение, как сделать доменные почтовые адреса.
Пока уже почти год юзеры(10 штук) не беспокоят. Гугл и все остальные в плане приложений поддерживают отличную политику — до 10Мб пересылай аттачментом, а больше — заливай на гуглдиск и давай ссылку. Имхо очень дисциплинирует.
Кстати, был опыт похожий с отечественным хостером – Яндекс ПДД.
Так вот, у них бывает, что письма уходят по нескольку часов. А в поддержке отвечают «Да, так и есть, терпите».
Полностью поддерживаю.
Так вот, у них бывает, что письма уходят по нескольку часов. А в поддержке отвечают «Да, так и есть, терпите».
до 10Мб пересылай аттачментом, а больше — заливай на гуглдиск и давай ссылку. Имхо очень дисциплинирует.
Полностью поддерживаю.
Тоже заметил что все форматы, связанные с электронной почтой (как формат писем так и протоколы), совершенно отвратительны и отбивают желание писать какой бы то ни было софт для их поддержки. А ещё эта зараза проникла в http под видом content-type multipart/form-data. А ещё наверно с этим как-то связано то, что конфиги известного серверного почтового софта (sendmail, exim) тоже смотрятся неадекватно.
По-моему в самом начале (70-е годы или около того) там было всё хорошо, но то ли они были малопригодны для расширения, то ли авторы первых расширений к ним были криворуки, но все последующие расширения к почтовым форматам выглядят сделанными и интегрированными в базовый формат абы как. А без всей этой кучи мусора современная почта уже не будет работать, к сожалению, и все новые реализации вынуждены её поддерживать.
По-моему в самом начале (70-е годы или около того) там было всё хорошо, но то ли они были малопригодны для расширения, то ли авторы первых расширений к ним были криворуки, но все последующие расширения к почтовым форматам выглядят сделанными и интегрированными в базовый формат абы как. А без всей этой кучи мусора современная почта уже не будет работать, к сожалению, и все новые реализации вынуждены её поддерживать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
К вопросу велосипедостроения в сфере электропочтового хранения