Из всех клонов и потомков Nagios болше всего мне пришелся по душе omdistro.
всё продумано, можно выбрать себе «морду» по эстетическим требованиям. Хочешь — nagios classic, icinga, suriken, WATO. NagVis в комплекте, настраивается всё очень разумно. За счёт того что check_mk написан на python куда приятнее пользоваться им, а он уж сам генерит конфиги для nagios core. Всячески рекомендую.
Xen как серверный гипервизор — мёртв. Остаётся как карманная игрушка цитрикса и всякая экзотика, типа виртуальных десктопов, сотовых телефонов и т.д. Плюс легаси инсталляции. Плюс amazon, который его активно in-house пилит (гипервизор в опенсорсе, userspace — in house).
Поясняю:
Xen родился как развитие идеи binary rewriting. Вместо того, чтобы патчить ОС «на ходу» для перехвата привилегированных инструкций, мы «патчим» её (ОС) при компиляции, за счёт чего имеем огромное ускорение. Это PV-режим работы гипервизора. Он рвал все существующие системы виртуализации на тот момент в клочки.
Потом интел выкатила VT и VT-D, и binary rewriting стал ненужен. Xen сделал морду кирпичом и выкатил HVM-режим, но тут уже начались всякие нюансики в реализации, и он начал гоняться с KVM/VMWare за процентики. Кто-то больше, кто-то меньше. В этот момент он потерял главное рыночное преимущество.
Дальше начались игры «следующего порядка»:
Xen: тяжёлый отвратительный userspace в dom0. xenstore с утечками памяти, залипающие домены, реверсные блочные устройства, шелловые скрипты как часть тулстека по инициализации гостевых устройств. Гигантская куча разрозненных кусков кода, пытающихся подружить разные части линукса с инородной странной сущностью за пределами ОС.
KVM: Виртуалка — это userspace процесс. Легко и просто.
Xen: абстракные computer science исследования — mirage (микроос на окамл для запуска приложений в pv-окружении), stub domains для изоляции «обратной части драйверов», микрочекпоинты (remus), etc.
KVM: то, что нужно индустрии прямо тут и сейчас.
Xen — чужеродная среда с кучей проблем (nvidia не поддерживает линукс и xen, grub+uefi+xen не работают вместе, etc), kvm — родное, нативное в ядре, qemu — всего лишь userspace приложение без каких-либо выкрутасов.
На выходе — на последнем ops-summit на openstack summit 2016-1, на сессии, посвящённой mitaka, в зале не было НИ ОДНОГО человека, кто бы использовал xen как гипервизор. Есть rackspace, который держит клиентские legacy-виртуалки на xenserver'е — но за кулисами их ребята страшно ругались на него, и используют они его не как «систему управления виртуальными машинами», а как прослойку между гипервизором и openstack'ом. Никаких пулов, никаких адских xapi на мастере, отжирающих 300% CPU и тупящих непонятно на чём.
xen всегда имел проблемы с opensource'ом. Адекватной системы сборки не было, и если сам гипервизор был прост и понятен, но его userspace — ужасен и местами имел дыры в проприетарные системы (цитрикса). Самому цитриксу оно особо не нужно и его интересуют маржинальные продукты (читай, виртуализация десктопов), а серверный рынок — только как часть портфолио и только в контексте энтерпайза.
Мораль этой истории, как я уже говорил, что рынок VPN очень насыщенный, сервисов очень много, и конкуренция очень жесткая. Поэтому если вам интересен этот бизнес и вы хотите им заниматься — готовьте деньги и ищите человека умеющего хорошо продавать в сети.
Вот знаете, я не делал никаких групп в социальных сетях и не продвигал VPN буквально нигде, кроме как здесь, на хабре, пару лет назад, а VPN создавался вообще для себя и друзей (и делался только потому, что это круто), просто перерос в нечто немного большее. О сервисе нет ни одного отзыва. Почему-то мне кажется, что у вас ситуация развивалась примерно так же. И не сказать, что клиентов мало, но и не дохрена — несколько сотен.
С количеством абуз вам действительно повезло, но с хостером — не особо. По крайней мере площадки, которые я использую, в курсе о VPN-as-a-service (еще иногда называют private VPN), и достаточно просто предпринимать какие-то действия по исправлению ситуации, они не отключают и не грозятся это сделать. Мне приходится справляться как минимум с одной в месяц (и не только с copyright infringement), и я это делаю достаточно не элегантно и не очень приятно для пользователей: сообщение о необходимости соблюдения правил отправляется всем, кто был подключен к серверу в момент прихода абузы, с объяснением, почему это письмо отправлено всем и для кого оно предназначено, ведь логгирование, естественно, не ведется.
Клиент, который у вас просил выделенный IP и документ, быть может (просто предположение!) хотел ходить на сайты, где есть ограничение по IP. В некоторые банки, например, у которых принудительное ограничение по IP (иногда такое встречается у юридических лиц) бывает проблематично попасть, используя, например, мобильный интернет, т.к. IP может выдаваться совершенно из разных диапазонов.
Мало кто знает, что в Туркменистане тоже все довольно жестко в плане регулирования интернета, и OpenVPN (и не только он) заблокирован во всей стране средствами DPI. Естественно, DPI отслеживает фингерпринт соединения, который очень сильно отличается от обычного TLS (HTTPS), хоть на какой порт вы бы его не вешали. Спасает либо SSH-туннель до этого же сервера с OpenVPN-подключением через этот туннель, либо что-то вроде stunnel или shadowsocks. В Китае все несколько сложнее, но тоже решаемо.
Многие VPN-сервисы (в том числе и популярные) сделаны просто отвратительно внутри. Кто-то до сих пор использует tap, когда вообще нет никакого резона пускать L2-трафик внутри туннеля, кто-то не проверяет EKU (или netscape-параметры-как-их-там) у сертификата, позволяя любому клиенту VPN-сервиса поднимать свой сервер, используя клиентский сертификат, и делать MiTM, у кого-то вообще проблемы с MTU и головой.
Должен сказать, ваш сервис был один из трех, по моему мнению, достойных.
тут палка о двух концах:
1. заблокировать бд и получить скорее мёртвое, чем живое приложение
2. отцепить от репликации слейва и снять дамп с актуальностью «10 минут назад»
в зависимости от условий выбирается одно из решений.
что не так? :-)
— Какая у вас средняя нагрузка — сколько данных в среднем пишется в Монгу? Сколько онлайн юзеров?
— Был ли включен journal'инг? Резервное копирование, отказоустойчивость? А отказоустойчивость на уровне Node?
— Какая задержка до получения отчетов считается нормальной? Агрегация за прошлый день или максимально близко к realtime?
— Чем не угодила та же ГуглАналитика (или ЯндексМетрика)? Из того что вы написали, вроде, все можно ею сделать///
— Почему не стандартный для такого класса задач набор Apache Storm — Hadoop/Spark?
— Есть уже готовые счетчики, которые вполне поддаются кастомизации, например, Snowplow. Чем они не угодили?
— Каким образом вы обрабатываете ситуацию когда надо отправить некоторое событие, но юзер сразу же закрывает вкладку/переходит на другую страницу?
— Буферизируете ли вы данные перед отправкой (несколько «пакетов» собрать в один и послать одним запросом)?
— Как по-вашему, оправдано ли хранить данные для счетчиков в памяти?
— Вы хоститесь на своих серверах или облако? Если облако, то какое?
— Если облако, то пользуетесь ли всякими «хаками» для освобождения памяти, типа сброса кеша ОС, что повлечет за собой уменьшение потребление памяти Монгой?
— Каков максимальный размер массива с PID'ами?
— Где и как генерируется PID?
— Что будете делать, если одного сервера с Node станет недостаточно? Какая максимальная производительность, по вашим оценкам, у одного сервера?
Понимаю, что на некоторые из этих вопросов вы уже дали ответы, просто хотелось бы более подробного рассказа. Спасибо!
К сожалению, Уважаемый автор судит исключительно со своей колокольни, не пытаясь посмотреть на ситуацию с позиции менеджера или топ менеджера. Проблема гораздо глубже и системнее чем кажется и имеет масштабы всей страны, а не отдельной службы внутри бюджетной организации. Попробую пояснить:
1) В стране идут структурные изменения, которые не очень афишируются. Идет укрупнение бюджетных структур — образование, медицина, оборонка. Причем кластеризация этих структур происходит не по принципу «кто эффективнее, тот и будет вокруг себя собирать кластер» а по принципу «своя рубашка ближе к телу», т.е. если руководитель бюджетной организации в хороших отношениях с руководством того или иного министерства, то ему и дают карт-бланш. С точки зрения ИТ, то систематизация и регламентация всех бизнес-процессов может привести к скорому поглощению этой организации ведь она «так понятна с точки зрения управления». Именно по этому руководство с опаской идет на автоматизацию деятельности, ведь на кнопочки нажимать в корпоративной ИС без проблем сможет и кто-то другой, а хаосом управлять может только «гениальный» руководитель.
2) ИТ не является основной бизес-единицей бюджетной организации. Рухнул сайт, не смогли граждане получить услугу через интернет, ничего, придут ножками, бумага то в организации движется, а значит работа идет, а значит все хорошо, а проблемы индейцев шерифа не волнуют.
3) Исходя из второго пункта, бюджетке никогда не достичь уровня заработных плат, который есть в коммерции. Плюс к этому, если покупаешь классного спеца за рыночную цену, эта информация мгновенно расходится по организации и все ходят, криво смотрят и за спиной шепчутся: «и за что ему платят такие деньги, он мне даже на ноль в екселе поделить не смог». Да именно так! Лишь единицы из тысяч сотрудников бюджетных организаций понимают в чем состоит работа Системного администратора и почему он так дорого стоит.
4) Исходя из третьего пункта, качество человеческого материала работающего в ИТ подразделениях ниже принтера, хотя и выше плинтуса. В этом случае задача менеджера заключается в том, что оторвать «тело» от игры, пнуть его в нужном направлении, причем с такой ювелирной точность, чтобы он по пути не накосячил. Ни о какой самостоятельности в принятии решений по устранению проблемы рядовым сотрудником речи не идет, но и это не самое страшное. Самое страшное, что рядовой сотрудник отказывается нести всяческую ответственность за свою работу со словами «вы мне и так мало платите». Ситуацию спасают только такие люди как Автор, которые готовы делать полезное дело за идею, а не за З/П. Я готов молиться на таких сотрудников, хотя и понимаю, что всему есть предел, поэтому стараюсь сделать по максимуму их руками, чтобы перед руководством обосновать, что эти люди важны и им нужно платить достойно.
5) Приведу аналогию об информационных системах как урна для мусора. Поставить урну для мусора безусловно важное, нужное и полезное дело, но! Ее нужно поставить в правильном месте, нужно сломать многолетнюю привычку у «пользователей» бросать мусор в урну, а не в месте его появления, нужно эту урну вовремя очищать, чтобы она не превратилась в локальную помойку. Возьмем систему HelpDesk. Ну поставим мы ее, ну заставим пользователей отправлять заявки только через нее, но что делать с ИТ-персоналом. Постоянные отмазы о ведении заявок: «я забыл завести, я забыл закрыть, да она сама закрылась». Наказывать? но как? И вот тут мы переходим к последней проблеме, о которой хочу рассказать, хотя их гораздо больше.
6) Управляемо то что измеряемо. Допустим мы разработаем метрики и сделаем гибкую оплату труда, которая привязана к результатам.
а) как правило подобная система оплаты труда идет в разрез теми правилами, которые приняты в бюджетной организации
б) расчетчики З/П взвоют, если я им начну носить каждый месяц разные данные о надбавках к «окладу», которые отражают те или иные заслуги сотрудников.
в) Фонд оплаты труда в бюджетке утверждается как минимум на год. Соответственно, чтобы кого-то поощрить, я должен у кого-то отнять. А если все одинаково хорошо работают, то мы придем к одинаково низкой З/П. Класс!
В качестве послесловия сей тирады хочу рассказать реальную историю:
Наши финансисты внедрили автоматизацию финансового блока (зарплата, бухгалтерия, планово-финансовая деятельность). Внедрили с помощью аутсорсеров, все здорово, но вот теперь никто не понимает как оно работает и считается. После этого «успешного» внедрения (Внимание!) финансисты замахнулись на автоматизацию основного производственного процесса, чтобы и там рулить его параметрами на свое усмотрение. Руководство это смекнуло и отдало проект по внедрению нам и с чувством выполненного долга и осознанием что решение было верным отстранилось. Мы набрали классных спецов, дали им рыночную З/П и ринулись в бой. Финансисты не забыли обиду и начали потихоньку под разными предлогами резать нам финансирование. Причем мотиация финансистов не отличается адекватностью, но право подписи на финансовых документах у них. Топ менеджер принципиально в это не вмешивается (о его мотивах даже рассуждать не буду). В итоге сейчас идет бодание между Айтишниками и финанситами. Угадайте, кто пока выигрывает? Но это пока!
Программеры — они толстые. Потому что они сидят. А админы — они тощие. Потому что бегают. Впрочем, бывают тощие программеры. Hо не надо думать, что это исключение из правил — это переученные админы. Также встречаются и толстые админы. Это обленившиеся программеры.
Программеры курят быстро, потому что мысль. Потому что она уйдет и придется думать ее снова. У админов мыслей нет, поэтому они курят медленно. Они делают это в те моменты, когда все работает и ничего не падает. Поэтому они курят редко.
Программеры ходят на обед сами. Они приносят много еды в офис и вкусно ей пахнут. Они едят ее прямо на клаве. Потому что мысль. Админы заказывают еду в офис. Потому что если они за ней пойдут, что-нибудь упадет. И придется бежать в офис с недоеденным гамбургером. Потому что админы любят питаться от Макдональдса. Потому что вкусно, а потолстеть им не грозит. Если они не обленившиеся программеры.
Программеры уходят с работы ночью. Потому что мысль. Hекоторые из них уходят вечером и думают мысль дома. Hекоторые, у которых есть ноутбук, думают ее в метро. Админы домой не ходят. Потому что если они пойдут домой, что-нибудь упадет. И придется идти на работу. А на работу они ходить не любят. И не ходят. Они там живут. У них обычно есть отдельное гнездо за отдельной дверью, часто запираемой на отдельный замок.
Программеры спят в выходной. Обычно это среда или понедельник. Потому что мысль. В понедельник мысли еще нет. А в среду идет переход от одной мысли к другой. Админы спят в гнезде. Из-за отдельтного замка в это время иногда раздается храп. Админы редко спят больше десяти минут. Потому что если проспать больше, что-нибудь упадет. И придется просыпаться по необходимости. А админы любят просыпаться сами, пусть и через десять минут.
Программеры пьют пиво. В основном светлое и много. Потому что мысль. Пока она плавает — ее можно думать. Главное, чтобы не утонула. Админы тоже пьют пиво. Потому что если что-нибудь упадет, им будет пофиг. Админы любят когда им пофиг. И программеры любят, когда им пофиг. Поэтому часто они пьют пиво вместе. И им вместе пофиг. После этого они спят. Hо не вместе. Админы спят в гнезде, а программеры — на клаве. Когда они просыпаются, они снова пьют пиво. Потому что хочется. Потому что они админы. И программеры.
Сумбурно, слишком много ненужного, а решается все гораздо проще.
1. Логировать отсылку почты умеет сам php, не обязательно для этого «насиловать» почтовик — mail.add_x_header и mail.log в помощь
2. Почтовик надо настраивать на предмет ограничения рассылки писем (например не более 500 в час), этим же еще и спасетесь от попадания в черные списки. Кроме того можно настроить уведомления о большой очереди и/или большой активности.
3. Поиск зловордов онлайн сканерами — это вообще зачем такое чудо чудное? Надо с причиной болезни разбираться, а не с последствиями.
Ищите локально!
Тот же ClamAV прекрасно найдет вам все залитые php-шеллы и прочую муть (впрочем, мейлеры, к сожалению, не найдет).
4. Можно попробовать ai-bolit. Хотя мой опыт на клиентских сайтах «отрицательный» — я так и не понял, как этим инструментом пользоваться. Находит очень много «подозрительных» файлов. Так много, что руками перебрать их нереально.
5. В первую очередь анализируйте логи веб-сервера!
grep «POST» на лог файл (и на все старые логи) и там будет прекрасно видно «левые» скрипты.
В 90% случаев взламывают через уязвимость какого-то из компонет/плагинов/проч. Через неё заливают шелл и потом уже делают все остальное.
хехе… у меня в чеклисте, для проверки нового сервера (как правило это какой-то клиентский сервер) есть такой скриптик который генерит мне вот такой вот вывод:
Один мой товарищ внедрял СПО на предприятии. Да, это не школа, свои нюансы. Так вот, тем кому не нравился Linux, LibreOffice начальство разрешало поставить Windows, MS Office на деньги вычтенные из их зарплаты. Результат: все быстро привыкли к Linux и LibreOffice.
всё продумано, можно выбрать себе «морду» по эстетическим требованиям. Хочешь — nagios classic, icinga, suriken, WATO. NagVis в комплекте, настраивается всё очень разумно. За счёт того что check_mk написан на python куда приятнее пользоваться им, а он уж сам генерит конфиги для nagios core. Всячески рекомендую.
Поясняю:
Xen родился как развитие идеи binary rewriting. Вместо того, чтобы патчить ОС «на ходу» для перехвата привилегированных инструкций, мы «патчим» её (ОС) при компиляции, за счёт чего имеем огромное ускорение. Это PV-режим работы гипервизора. Он рвал все существующие системы виртуализации на тот момент в клочки.
Потом интел выкатила VT и VT-D, и binary rewriting стал ненужен. Xen сделал морду кирпичом и выкатил HVM-режим, но тут уже начались всякие нюансики в реализации, и он начал гоняться с KVM/VMWare за процентики. Кто-то больше, кто-то меньше. В этот момент он потерял главное рыночное преимущество.
Дальше начались игры «следующего порядка»:
Xen: тяжёлый отвратительный userspace в dom0. xenstore с утечками памяти, залипающие домены, реверсные блочные устройства, шелловые скрипты как часть тулстека по инициализации гостевых устройств. Гигантская куча разрозненных кусков кода, пытающихся подружить разные части линукса с инородной странной сущностью за пределами ОС.
KVM: Виртуалка — это userspace процесс. Легко и просто.
Xen: абстракные computer science исследования — mirage (микроос на окамл для запуска приложений в pv-окружении), stub domains для изоляции «обратной части драйверов», микрочекпоинты (remus), etc.
KVM: то, что нужно индустрии прямо тут и сейчас.
Xen — чужеродная среда с кучей проблем (nvidia не поддерживает линукс и xen, grub+uefi+xen не работают вместе, etc), kvm — родное, нативное в ядре, qemu — всего лишь userspace приложение без каких-либо выкрутасов.
На выходе — на последнем ops-summit на openstack summit 2016-1, на сессии, посвящённой mitaka, в зале не было НИ ОДНОГО человека, кто бы использовал xen как гипервизор. Есть rackspace, который держит клиентские legacy-виртуалки на xenserver'е — но за кулисами их ребята страшно ругались на него, и используют они его не как «систему управления виртуальными машинами», а как прослойку между гипервизором и openstack'ом. Никаких пулов, никаких адских xapi на мастере, отжирающих 300% CPU и тупящих непонятно на чём.
xen всегда имел проблемы с opensource'ом. Адекватной системы сборки не было, и если сам гипервизор был прост и понятен, но его userspace — ужасен и местами имел дыры в проприетарные системы (цитрикса). Самому цитриксу оно особо не нужно и его интересуют маржинальные продукты (читай, виртуализация десктопов), а серверный рынок — только как часть портфолио и только в контексте энтерпайза.
location /.well-known/acme-challenge {
root /var/www/letsencrypt/;
}
Генерация сертфиката:
./letsencrypt-auto certonly --webroot -w /var/www/letsencrypt -d domain.com
С количеством абуз вам действительно повезло, но с хостером — не особо. По крайней мере площадки, которые я использую, в курсе о VPN-as-a-service (еще иногда называют private VPN), и достаточно просто предпринимать какие-то действия по исправлению ситуации, они не отключают и не грозятся это сделать. Мне приходится справляться как минимум с одной в месяц (и не только с copyright infringement), и я это делаю достаточно не элегантно и не очень приятно для пользователей: сообщение о необходимости соблюдения правил отправляется всем, кто был подключен к серверу в момент прихода абузы, с объяснением, почему это письмо отправлено всем и для кого оно предназначено, ведь логгирование, естественно, не ведется.
Клиент, который у вас просил выделенный IP и документ, быть может (просто предположение!) хотел ходить на сайты, где есть ограничение по IP. В некоторые банки, например, у которых принудительное ограничение по IP (иногда такое встречается у юридических лиц) бывает проблематично попасть, используя, например, мобильный интернет, т.к. IP может выдаваться совершенно из разных диапазонов.
Мало кто знает, что в Туркменистане тоже все довольно жестко в плане регулирования интернета, и OpenVPN (и не только он) заблокирован во всей стране средствами DPI. Естественно, DPI отслеживает фингерпринт соединения, который очень сильно отличается от обычного TLS (HTTPS), хоть на какой порт вы бы его не вешали. Спасает либо SSH-туннель до этого же сервера с OpenVPN-подключением через этот туннель, либо что-то вроде stunnel или shadowsocks. В Китае все несколько сложнее, но тоже решаемо.
Многие VPN-сервисы (в том числе и популярные) сделаны просто отвратительно внутри. Кто-то до сих пор использует tap, когда вообще нет никакого резона пускать L2-трафик внутри туннеля, кто-то не проверяет EKU (или netscape-параметры-как-их-там) у сертификата, позволяя любому клиенту VPN-сервиса поднимать свой сервер, используя клиентский сертификат, и делать MiTM, у кого-то вообще проблемы с MTU и головой.
Должен сказать, ваш сервис был один из трех, по моему мнению, достойных.
1. заблокировать бд и получить скорее мёртвое, чем живое приложение
2. отцепить от репликации слейва и снять дамп с актуальностью «10 минут назад»
в зависимости от условий выбирается одно из решений.
что не так? :-)
— Был ли включен journal'инг? Резервное копирование, отказоустойчивость? А отказоустойчивость на уровне Node?
— Какая задержка до получения отчетов считается нормальной? Агрегация за прошлый день или максимально близко к realtime?
— Чем не угодила та же ГуглАналитика (или ЯндексМетрика)? Из того что вы написали, вроде, все можно ею сделать///
— Почему не стандартный для такого класса задач набор Apache Storm — Hadoop/Spark?
— Есть уже готовые счетчики, которые вполне поддаются кастомизации, например, Snowplow. Чем они не угодили?
— Каким образом вы обрабатываете ситуацию когда надо отправить некоторое событие, но юзер сразу же закрывает вкладку/переходит на другую страницу?
— Буферизируете ли вы данные перед отправкой (несколько «пакетов» собрать в один и послать одним запросом)?
— Как по-вашему, оправдано ли хранить данные для счетчиков в памяти?
— Вы хоститесь на своих серверах или облако? Если облако, то какое?
— Если облако, то пользуетесь ли всякими «хаками» для освобождения памяти, типа сброса кеша ОС, что повлечет за собой уменьшение потребление памяти Монгой?
— Каков максимальный размер массива с PID'ами?
— Где и как генерируется PID?
— Что будете делать, если одного сервера с Node станет недостаточно? Какая максимальная производительность, по вашим оценкам, у одного сервера?
Понимаю, что на некоторые из этих вопросов вы уже дали ответы, просто хотелось бы более подробного рассказа. Спасибо!
1) В стране идут структурные изменения, которые не очень афишируются. Идет укрупнение бюджетных структур — образование, медицина, оборонка. Причем кластеризация этих структур происходит не по принципу «кто эффективнее, тот и будет вокруг себя собирать кластер» а по принципу «своя рубашка ближе к телу», т.е. если руководитель бюджетной организации в хороших отношениях с руководством того или иного министерства, то ему и дают карт-бланш. С точки зрения ИТ, то систематизация и регламентация всех бизнес-процессов может привести к скорому поглощению этой организации ведь она «так понятна с точки зрения управления». Именно по этому руководство с опаской идет на автоматизацию деятельности, ведь на кнопочки нажимать в корпоративной ИС без проблем сможет и кто-то другой, а хаосом управлять может только «гениальный» руководитель.
2) ИТ не является основной бизес-единицей бюджетной организации. Рухнул сайт, не смогли граждане получить услугу через интернет, ничего, придут ножками, бумага то в организации движется, а значит работа идет, а значит все хорошо, а проблемы индейцев шерифа не волнуют.
3) Исходя из второго пункта, бюджетке никогда не достичь уровня заработных плат, который есть в коммерции. Плюс к этому, если покупаешь классного спеца за рыночную цену, эта информация мгновенно расходится по организации и все ходят, криво смотрят и за спиной шепчутся: «и за что ему платят такие деньги, он мне даже на ноль в екселе поделить не смог». Да именно так! Лишь единицы из тысяч сотрудников бюджетных организаций понимают в чем состоит работа Системного администратора и почему он так дорого стоит.
4) Исходя из третьего пункта, качество человеческого материала работающего в ИТ подразделениях ниже принтера, хотя и выше плинтуса. В этом случае задача менеджера заключается в том, что оторвать «тело» от игры, пнуть его в нужном направлении, причем с такой ювелирной точность, чтобы он по пути не накосячил. Ни о какой самостоятельности в принятии решений по устранению проблемы рядовым сотрудником речи не идет, но и это не самое страшное. Самое страшное, что рядовой сотрудник отказывается нести всяческую ответственность за свою работу со словами «вы мне и так мало платите». Ситуацию спасают только такие люди как Автор, которые готовы делать полезное дело за идею, а не за З/П. Я готов молиться на таких сотрудников, хотя и понимаю, что всему есть предел, поэтому стараюсь сделать по максимуму их руками, чтобы перед руководством обосновать, что эти люди важны и им нужно платить достойно.
5) Приведу аналогию об информационных системах как урна для мусора. Поставить урну для мусора безусловно важное, нужное и полезное дело, но! Ее нужно поставить в правильном месте, нужно сломать многолетнюю привычку у «пользователей» бросать мусор в урну, а не в месте его появления, нужно эту урну вовремя очищать, чтобы она не превратилась в локальную помойку. Возьмем систему HelpDesk. Ну поставим мы ее, ну заставим пользователей отправлять заявки только через нее, но что делать с ИТ-персоналом. Постоянные отмазы о ведении заявок: «я забыл завести, я забыл закрыть, да она сама закрылась». Наказывать? но как? И вот тут мы переходим к последней проблеме, о которой хочу рассказать, хотя их гораздо больше.
6) Управляемо то что измеряемо. Допустим мы разработаем метрики и сделаем гибкую оплату труда, которая привязана к результатам.
а) как правило подобная система оплаты труда идет в разрез теми правилами, которые приняты в бюджетной организации
б) расчетчики З/П взвоют, если я им начну носить каждый месяц разные данные о надбавках к «окладу», которые отражают те или иные заслуги сотрудников.
в) Фонд оплаты труда в бюджетке утверждается как минимум на год. Соответственно, чтобы кого-то поощрить, я должен у кого-то отнять. А если все одинаково хорошо работают, то мы придем к одинаково низкой З/П. Класс!
В качестве послесловия сей тирады хочу рассказать реальную историю:
Наши финансисты внедрили автоматизацию финансового блока (зарплата, бухгалтерия, планово-финансовая деятельность). Внедрили с помощью аутсорсеров, все здорово, но вот теперь никто не понимает как оно работает и считается. После этого «успешного» внедрения (Внимание!) финансисты замахнулись на автоматизацию основного производственного процесса, чтобы и там рулить его параметрами на свое усмотрение. Руководство это смекнуло и отдало проект по внедрению нам и с чувством выполненного долга и осознанием что решение было верным отстранилось. Мы набрали классных спецов, дали им рыночную З/П и ринулись в бой. Финансисты не забыли обиду и начали потихоньку под разными предлогами резать нам финансирование. Причем мотиация финансистов не отличается адекватностью, но право подписи на финансовых документах у них. Топ менеджер принципиально в это не вмешивается (о его мотивах даже рассуждать не буду). В итоге сейчас идет бодание между Айтишниками и финанситами. Угадайте, кто пока выигрывает? Но это пока!
Программеры курят быстро, потому что мысль. Потому что она уйдет и придется думать ее снова. У админов мыслей нет, поэтому они курят медленно. Они делают это в те моменты, когда все работает и ничего не падает. Поэтому они курят редко.
Программеры ходят на обед сами. Они приносят много еды в офис и вкусно ей пахнут. Они едят ее прямо на клаве. Потому что мысль. Админы заказывают еду в офис. Потому что если они за ней пойдут, что-нибудь упадет. И придется бежать в офис с недоеденным гамбургером. Потому что админы любят питаться от Макдональдса. Потому что вкусно, а потолстеть им не грозит. Если они не обленившиеся программеры.
Программеры уходят с работы ночью. Потому что мысль. Hекоторые из них уходят вечером и думают мысль дома. Hекоторые, у которых есть ноутбук, думают ее в метро. Админы домой не ходят. Потому что если они пойдут домой, что-нибудь упадет. И придется идти на работу. А на работу они ходить не любят. И не ходят. Они там живут. У них обычно есть отдельное гнездо за отдельной дверью, часто запираемой на отдельный замок.
Программеры спят в выходной. Обычно это среда или понедельник. Потому что мысль. В понедельник мысли еще нет. А в среду идет переход от одной мысли к другой. Админы спят в гнезде. Из-за отдельтного замка в это время иногда раздается храп. Админы редко спят больше десяти минут. Потому что если проспать больше, что-нибудь упадет. И придется просыпаться по необходимости. А админы любят просыпаться сами, пусть и через десять минут.
Программеры пьют пиво. В основном светлое и много. Потому что мысль. Пока она плавает — ее можно думать. Главное, чтобы не утонула. Админы тоже пьют пиво. Потому что если что-нибудь упадет, им будет пофиг. Админы любят когда им пофиг. И программеры любят, когда им пофиг. Поэтому часто они пьют пиво вместе. И им вместе пофиг. После этого они спят. Hо не вместе. Админы спят в гнезде, а программеры — на клаве. Когда они просыпаются, они снова пьют пиво. Потому что хочется. Потому что они админы. И программеры.
sudo !!1. Логировать отсылку почты умеет сам php, не обязательно для этого «насиловать» почтовик — mail.add_x_header и mail.log в помощь
2. Почтовик надо настраивать на предмет ограничения рассылки писем (например не более 500 в час), этим же еще и спасетесь от попадания в черные списки. Кроме того можно настроить уведомления о большой очереди и/или большой активности.
3. Поиск зловордов онлайн сканерами — это вообще зачем такое чудо чудное? Надо с причиной болезни разбираться, а не с последствиями.
Ищите локально!
Тот же ClamAV прекрасно найдет вам все залитые php-шеллы и прочую муть (впрочем, мейлеры, к сожалению, не найдет).
4. Можно попробовать ai-bolit. Хотя мой опыт на клиентских сайтах «отрицательный» — я так и не понял, как этим инструментом пользоваться. Находит очень много «подозрительных» файлов. Так много, что руками перебрать их нереально.
5. В первую очередь анализируйте логи веб-сервера!
grep «POST» на лог файл (и на все старые логи) и там будет прекрасно видно «левые» скрипты.
В 90% случаев взламывают через уязвимость какого-то из компонет/плагинов/проч. Через неё заливают шелл и потом уже делают все остальное.
А статья ни о чем, простите :)
Как раз собраны все эти тулзы (кроме lshw), но с учетом того чтобы не потребовалось root привилегий или доп. утилит
Пробел после /usr. Меня тогда пронесло, не успел обновится.