Метка «системное администрирование»

Привет, %username%! Готов поспорить, что рано или поздно все сисадмины относительно небольших компаний сталкиваются с такой волшебной задачей от руководства, как составление проекта развития ИТ-инфраструктуры компании. Особенно если тебе предложили должность и сразу же попросили составить план развития и бюджетирования. Вот и мне однажды поставили такую задачу. О всех подводных камнях, с которыми можно столкнуться я и опишу. Всем заинтересовавшимся велкам под кат!

Читать полностью »

Во время поиска нового места работы, мне пришла в голову мысль проанализировать текущее состояние рынка труда системных администраторов на предмет востребованности различных навыков у работодателей.
Чего ждут работодатели от системных администраторов? - 1

Данные были взяты с одного очень известного в России ресурса по поиску работы и действительны по состоянию на середину ноября 2014 года.
Читать полностью »

Соотносим потребности бизнеса с его возможностями

Планирование аварийного восстановления. Часть третья — заключительная

В предыдущих статьях (1,2), посвященных вопросам планирования аварийного восстановления, были описаны процедуры сбора и обработки информации об ИТ-инфраструктуре организации, позволяющие получить точную информацию о:

  • ИТ-сервисах, критичных для бизнеса компании,
  • Текущем времени восстановления их работы в случае сбоя,
  • Минимально достижимых сроках аварийного восстановления,
  • Необходимых ресурсах для их достижения.

И все бы ничего, если бы не ограниченные финансовые возможности организации, не позволяющие приобрести все необходимые резервы для оперативного восстановления. По этой причине заключительная задача планирования аварийного восстановления – поиск баланса между потребностями и финансовыми возможностями бизнеса, и закрепление его в виде соглашения об уровне обслуживания (Service Level Agreement – SLA) в части устранения возникающих инцидентов.

Данный этап полностью состоит из согласования с руководством компании следующих аспектов взаимодействия:Читать полностью »

В предыдущей нашей статье были рассмотрены основные возможности системы Traffic Inspector, включая прокси-сервер, SMTP-шлюз, правила тарификации, сетевую защиту, балансировку нагрузки, а также учет и фильтрацию трафика. Теперь мы бы хотели сравнить функциональность Traffic Inspector с возможностями аналогичных комплексных решений для управления ИТ-инфраструктурой.

Несмотря на большое количество весьма качественных прокси-серверов (например, Handycache) и систем учета трафика (таких как BWMeter и Internet Access Monitor), большинство из них являются, по сути, узкоспециализированными продуктами и решают, как правило, одну-две задачи. Между тем действительно комплексных решений, которым можно полностью доверить управление сетевой активностью, не так уж и много. Наиболее известные из них (помимо Traffic Inspector) – это Kerio Control, Lan2net, UserGate и Microsoft ForeFront TMG, разработка и продажа которого, к сожалению, прекращена в 2012 году. О них мы и поговорим.

Читать полностью »

Вот уже много лет пользователей Nginx мучает один и тот же вопрос: «Как можно ограничить скорость в целом для IP адреса независимо от числа сессий (соединений)? Почему Nginx этого не умеет? Почему разработчики Nginx так упорно не хотят реализовать этот простой функционал?» И ответить мне им нечего, о чём думают разработчики Nginx — не понятно и известно, наверное, только господу богу.

Бороться с этим можно по разному, кто-то использует скрипты на подобие htb.init, кто-то пишет скрипты шейпинга самостоятельно и делится удачным опытом на Хабре, а некоторые и вовсе используют PHP для ограничения скорости отдачи файлов. Только представьте себе, каким будет оверхед и расход памяти, при использовании PHP в подобных целях.
Читать полностью »

Готовимся к любым падениям

Планирование аварийного восстановления. Вторая часть

Это продолжение цикла публикаций, посвященных вопросам планирования аварийного восстановления. В предудущей статье речь шла об определении зоны планирования и нахождении точек отказа, которые могут приводить к сбоям в работе пользовательских сервисов. Следующий шаг – опираясь на информацию о точках отказа определить минимально возможные сроки устранения инцидентов, которые могут обеспечить технические специалисты при наличии всех необходимых ресурсов.

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

Определяем места, где стоит подстелить соломку

Планирование аварийного восстановления. Часть первая

Отказы в работе информационных систем – события, которые невозможно исключить полностью. Вне зависимости от причин случившегося сбоя, в момент его возникновения на системного администратора ложится груз ответственности по оперативному восстановлению работоспособности не только ИТ-систем, но и бизнеса в целом.

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

В первой статье речь пойдет об определении зоны планирования, или поиске тех инфраструктурных элементов, отказ в работе которых негативно влияет на частоту пульса системного администратора. Итак, по порядку:Читать полностью »

У нас в конторе, есть бизнес-приложение работающее с WebSphere версии 7.1, пользователи в этом приложении авторизуются через Active Directory. Для этого в WebSphere мы использовали метод авторизации Отдельный реестр LDAP. В этом случае можно указать домен или ещё какой каталог LDAP для авторизации. С появление второго домена, потребовалось авторизовывать пользователей из обоих доменов. Для этих целей мы поменяем метод авторизации на Объединённые хранилища. И ниже опишу как это всё настроить.
Читать полностью »

Преамбула

Представьте, что есть некое предприятие. Разумеется, с business-critical архитектурой. Любой простой – потеря денег. Сеть для предприятия строил интегратор. К экспертам этого же интегратора бегают инженеры предприятия за советом и моральной поддержкой. Формально, договора поддержки нет. Но взаимодействие есть, в том числе и потому, что у предприятия каждый год есть время для бюджетирования и это очень хорошо для интегратора, когда о тебе помнят. Несложно предположить, что при серьезной аварии, которую не смогут устранить в приемлемые сроки, нельзя будет найти виновного(но можно наказать невиновных и наградить непричастных!).
Читать полностью »

Лучше один раз день потерять, а потом за 5 минут все согласовать

Памятка по составлению ИТ бюджета

Формирование бюджета и обоснование затрат на ИТ — достаточно простая процедура, которая позволяет руководству компании увидеть выгоды инвестирования в технологии, а техническим специалистам разделять ответственность за состояние ИТ-инфраструктуры с руководством.

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

Планирование бюджета на ИТ можно разделить на три этапа: Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js