athacker

А в логах самого php-fpm что?

Тонкий клиент на месте + RDP-подключение к своему компу. Для транспорта RDP между офисами можно либо VPN настроить, либо в основном офисе RDG (Remote desktop gateway) поднять.

В логах самого заббикса что пишут?

Как написать регламент технической поддержки?

Как, как -- с помощью любезно предоставленных алфавитом букв :-)

А если серьёзно -- начните писать, а потом будете допиливать. В каждом случае регламенты разные, и регламентируют разные вещи, с разными показателями.

Регламент включает в себя: процесс получения техподдержки (что пользователь должен сделать, чтобы обратиться в саппорт -- какие каналы обращения -- (специальная тикет-система, или письмо на определённый ящик, или это в телефон нужно позвонить, или в месенджер написать)).

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

Как определяются сроки обработки обращений?

Каковы этапы решения заявок? (например: Новая --> Назначена исполнителю --> В работе <--> Отложена -- > Решена --> Закрыта).

Как-то так.

Проверьте настройки контроллера и перемычки на дисках. И там и там есть возможность установить скорость обмена.

Товарищ, вы упоролись, что ли? Какой скрипт? Дамп трафика снимается (если на пальцах) путём работы со специальными интерфейсами ядра. Никакой скрипт на этом уровне работать не сможет. Ставьте tcpdump и смотрите трафик. Если нельзя ничего поставить -- настраивайте SPAN-на коммутаторе, подключайте туда юниксовую машину и смотрите tcpdump'ом трафик там. Если и это нельзя -- тогда смиритесь.

Конвергентные решения рассматривайте. Чтобы гипервизоры и storage одними и теми же серверами обеспечивались. Из опенсорсных -- Ceph, из платных -- ScaleIO, ONTAP Select, StoreVirtual. ScaleIO можно разворачивать и крутить бесплатно, но техподдержки не будет.

Штатные телепаты в отпуске. Логи с сервера и с клиентского микротика хотя бы процитируйте.

Смотря какая виртуализация. VMware distributed switch может netflow сам отгружать, достаточно настроить и поднять netflow-коллектор (nfcapd, например).

Капец вы там с предыдущим комментатором наговорили :-)

Для резервирования отправки вам нужно два почтовых релея и настроенный VRRP/CARP между ними. Т. е. на хостах поднимается виртуальный IP, который переедет на второй хост в случае падения первого.

Для приёма это тоже будет работать, если у вас два физически разных канала от одного и того же провайдера. Т.е. если можно с одним IP вещать по разным каналам. Но наверное, будет логичнее подключить 2 хоста к двум разным провайдерам, на разные IP, и сделать в DNS две MX-записи с различным приоритетом (10 и 20). Если 10-ый не будет доступен, отправители снаружи будут слать почту на 20-ый.

И да, не забывается, что помимо отправки почты наружу и получения почты снаружи есть ещё задача раздачи почты пользователям :-) Т. е. даже если у вас два SMTP-сервера, и принять почту они смогут почти гарантированно (при грамотной настройке ;-) ), то нужно ещё, чтобы они также гарантированно могли положить её на тот сервер, с которого пользователи не менее гарантированно смогут её забрать ;-) Что приводит нас к схеме либо 4-х серверов (два SMTP и два IMAP/POP3), либо трёх серверов -- два SMTP, который также раздают почту по IMAP/POP3, и один сервер-хранилище почты, подключенный к обоим серверам как общее хранилище.

Очевидно, что ваш хост работает нормально, если по локалке всё отдаётся.

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

Отдельный вопрос -- если у вас хост с серым IP, то как вам поможет DDNS? Тут чудо скорее в том, что вы вообще снаружи получаете доступ к своему компу :-)

www.sftpnetdrive.com

ESXi free

Ситикэт правильно говорит. Для обеспечения ваших нужды нужны три разные программы. Трекер, возможно, со встроенным функционалом a la wiki. Редмайн для этого вполне подходит, да. Как вариант -- можно посмотреть на YouTrack. До 10 пользователей бесплатно можно пользоваться. Но ютрек -- это чистый таск-трекер. Там нет возможности документацию вести.

Пароли -- нужно использовать менеджер паролей. Мы юзаем KeePass, он неплох.

Хранение конфигов/скриптов -- SVN. Некоторые предпочитают гит, но на мой взгляд, для хранения конфигов он не подходит. Одна только необходимость тащить локально всю репу на каждый сервер (т. е. все конфиги всех серверов) уже ставит под большое сомнение возможность его использования в этом сценарии. Да, это обходится -- можно выдёргивать отдельные участки репы, но это уже пляски с бубном. SVN для хранения конфигов подходит гораздо лучше.

Скрипты да, можно хранить в чём угодно. Но с точки зрения инфраструктуры, я бы не плодил лишние сущности, т. е. если использовать SVN для хранения конфигов, то там же лучше и скрипты хранить.

Мы делали в своё время систему сбора и хранения конфигов на базе SVN, с авто-коммитами раз в сутки и рассылкой оповещений по сделанным изменениям на мыло всем в отделе. Причём авто-коммит не рассылался, рассылались только оповещения при ручных коммитах, т. е. там, где были комментарии к коммитам.

Для документирования -- любой движок, например, тот же dokuwiki.

И насчёт доступа фрилансерам тоже правильно сказали -- фрилансеру выдаётся временный аккаунт в таск-трекере, выдаются временные необходимые доступы, и при закрытии задачи всё зачищается. Если ему нужны какие-то документашки, то наверное, проще их экспортировать в PDF и ему скидывать.

> Ну и под админом сижу, потому что вроде не параноик

Молодец, чо. Сейчас вам залили майнер, в следующий раз зальют шифровальщик. Зато "не параноик".