О профпригодности

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

P.S. Помниться сервак у нас накрылся HP-шный — мать сгорела, а вместе с ней и рейд-контроллер и 8-шт SAS дисков, на которых база бухгалтерии крутилась. Авария в ночь случилась, как раз за день перед этим полный бэкап снимали — собирались переводить базу на скуль на новый сервер. Авария так сказать ускорила процесс. Можно сказать, что повезло, что был полный бэкап. Но даже если бы не было полного, то собрали бы по кусочкам из инкрементного бэкапа. Главное — бэкап должен быть на другой физической машине.

чем у корпоративной почты, которая живет на куче серверов.

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

Но ТС привел пример, не очень надежной модели корпоративной почты.

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

Мое лично мнение, почта (особенно если это важный сегмент информации), должна храниться в нескольких местах. На почтовом сервере небольшая часть, так сказать буфер-приемник. Архив почтового файла на ПК пользователя И на специальном сервере — отдельной физической машине от почтового сервера. Таким образом «смерть» одного любого компонента из этой связки не приведет к потере информации.

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

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

Мне вот прям безумно интересно, что ж за важность такая.

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

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

Это ты к чему ляпнул? Да бэкапы нужны, но тебе же сказали их нет.

где ты блин вычитал что ТС дал ему задание?

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

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

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

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

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

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

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

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

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

По желанию (требованию) сотрудников ИТ, почтовый файл буфер-приемник так же может риплицироваться в локальный файл на ПК пользователя и/или локальный файл на сервере хранения.

Клиент почтовые сообщения или удаляет, или отправляет их в архив — постоянное место хранения почтовых сообщений.

Тогда всё хорошо, я просто упустил этот момент.

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

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

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

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

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

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

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

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

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

Но ТС в этом треде ноет и перекладывает вину на стажера

ну это святое -.-

как ни странно зерно истины есть.

всё таки админа протёршего базу стоит наказать.

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

а не надо на сисадминах экономить. в итоге дешевле выйдет.

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

ЩИТО

тебе не нужно.

Сейчас думаю, оставлять или нет? Он у нас на испытательном.

Давать сотруднику на испытательном возможность такое сделать, вот это настоящее ССЗБ.

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

У тебя аватарка на продукты переработки похожа.

Да, это продукт переработки древесины. Орех, лак, искусство... короче, ты не поймешь ;-)

Два дня прошло. Публика жаждет подробностей произошедшего

Ну и чем всё разрешилось?