Архив

Публикации с меткой ‘Дела админские’

Книга рецептов системного администратора #3: делите диски!

27 сентября 2014

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

Я скажу еще конкретнее: если вы не делите диски на разделы — вы — полный и безоговорочный мудак.

В подтверждение тому — история: покупаем проектировщику новый ноутбук с террабайтным диском. Система предустановлена, разбить диск на разделы теперь можно только утилитами типа Acronis Disk Director. Предлагаю коллеге этим и заняться. Тот отмахивается, мол, атавизм это. Договариваемся о том, что если с ноутбуком что-то случится — заниматься переносом данных будет поручено лично ему. Проходит полгода. Приношу на работу ноутбук родственницы, на котором не загружается система. Пытаюсь докопаться до причины, но ничего путного не выходит, и решаю переустановить систему. Благо ноутбук в безопасном режиме загружается, а диск разбит на разделы. Приходит вышеупомянутый проектировщик — его ноутбук тоже не загружается. Совсем никак. Вирус, наверное. Торжественно вручаю его коллеге.

Я: в безопасном режиме переношу данные с рабочего стола на второй раздел (2 клика мышкой, 15 минут), запускаю переустановку системы с флешки (30 минут), устанавливаю драйверы (лежали в отдельной папочке на диске D: — еще раз спасибо мне из прошлого!), потом возвращаю на место MS Office, антивирус, видеоплейер и кодеки (30 минут), создаю на рабочем столе ярлыки на папки с данными (1 минута).
Коллега: разбирает ноутбук (30 минут), снимает жесткий диск, подключает его к своему компьютеру (15 минут), переносит данные (5 часов — там данных под 700 Гбайт), снимает диск, возвращает его в ноутбук (30 минут), переустанавливает систему (30 минут), устанавливает ПО (30 минут), копирует данные по сети (1 сутки), понимает, что процесс идет слишком долго, переносит данные на портативный жесткий диск (5 часов), подключает портативный диск к ноутбуку, возвращает данные на место (5 часов).

Мой итог: примерно 1.5 часа.
Его итог: примерно 3 дня.

Книга рецептов системного администратора

За бюрократию, или почему документировать все-таки надо

Intro

Подавляющее большинство ИТ-специалистов-Made-In-Russia категорически не признает важность ведения документации. Это менталитет, это привычки, это воспитание. Это борьба с системой, берущая начало со школьной скамьи, когда будущему ИТ-специалисту учительница разрисовывала дневник красной ручкой за его неаккуратное ведение, а родители давали по шее за разгильдяйство. После школы будущий ИТ-специалист пристраивался в институт, и борьба с системой продолжалась: конспекты не писались, семинары не стенографировались, а лабораторные работы вообще выполнялись на черновиках, которые попросту выбрасывались. А перед экзаменом начинался штурм ботаников с целью отксерить/переписать заветный материал, ведущий к «удовл.» в зачетной книжке. В общем-то это культура. Национальная традиция, если хотите.

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

Печальная перспектива, правда? Но это если вы – владелец бизнеса, или хотя бы лицо, заинтересованное в эффективных бизнес-процессах на предприятии. Если же вы – ИТ-специалист, то для вас перспектива еще печальнее. Зачастую будет быстрее и проще все переделать «под себя», нежели разбираться, как и что работало раньше.

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

Доводы «за»

Аксиома №1. Документация необходима бизнесу.

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

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

Аксиома №2. Документация необходима ИТ-специалистам.

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

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

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

Таким образом документация сокращает время реакции на инциденты и их локализацию.

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

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

Другой момент: к вам обратился пользователь с просьбой установить на его компьютер важное приложение «World of Warcraft». Если у вас нет четко определенного и утвержденного генеральным директором перечня допустимого ПО, то нет и оснований ему в этом отказать. А с перечнем вы – хозяин ситуации. Причем, можно отказать без риска испортить с коллегой отношения: дескать, «я бы и рад, да не положено, извините».

Аксиома №3. Ведение документации – востребованный навык.

Надо признать, что в нашей стране развитие бизнеса в целом и отрасли ИТ в частности основывается на опыте более продвинутых западных коллег. Западные отраслевые стандарты, выраженные в методологиях ITIL, MOF и CobiT, четко определяют документирование как один из ключевых процессов управления ИТ. Рост ИТ-специалиста проходит по стандартной схеме «от меньшего к большему». Иными словами, от ООО «Рога и Копыта» до ОАО «Газпром». ИТ-специалист, не владеющий ключевыми навыками, шансов устроиться на престижную и высокооплачиваемую работу в крупную компанию практически не имеет. Так что учиться, учиться и еще раз учиться.

Перечень документации из серии Must Have

 Итак, какого рода документацию вести необходимо?

  1. Техническую. Это карта серверов, схемы подключения коммутационного оборудования, конфигурации сервисов и ПО, описание и схема подключения оргтехники, структура сети, используемых протоколов, описание и алгоритмы работы телефонии, график и схема резервного копирования. Сюда же можно отнести типовые процедуры (например, подготовка новой рабочей станции к эксплуатации) и контрольные списки.
  2. Организационную. Это регламент использования ресурсов корпоративной сети, перечень разрешенного ПО, SLA, процедуры приема и увольнения сотрудников.
  3. Справочную. Это справочники (телефоны, реквизиты поставщиков оборудования, ПО, телекоммуникационных услуг), журналы учета изменений, резервного копирования, процедуры заказа и приемки оборудования, перечень используемых расходных материалов и т. д.
  4. Сопроводительную. Инструкции для сотрудников и ИТ-персонала.

Где и как вести документацию

Одним из лучших способов хранения и управления документацией общепризнанно является применение CMDB (Configuration Management Database). Разработанный в качестве компонента процесса Управления конфигурациями ITIL, это гибкий и мощный репозиторий информации о компонентах информационных систем. «Лучшая практика», так сказать. Другая сторона медали – коммерческие CMDB достаточно дороги и для бюджетов малого и среднего бизнеса часто неподъемны.

Если денег на CMDB нет, то при определении базы хранения и методов управления документацией важно учесть 2 качественные характеристики: интерактивность и доступность. С документацией чаще всего работает не один человек, а коллектив, поэтому лучше использовать привычно сочетающиеся с совместной работой инструменты: wiki, web-платформы (например, Microsoft SharePoint или его бесплатные реализации), CMS. Такие системы позволят наглядно структурировать документацию, четко прослеживать взаимосвязи, отслеживать версионность и обеспечить максимальную доступность. В любом случае, понимание приходит с опытом. Главное начать, а уж наиболее удобный способ выработается сам собой.

Outro

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

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

Default , , ,

Вы хотите стать системным администратором? Подумайте еще раз!

12 июля 2011

Работать в ИТ стало модно. Молодые люди, ищущие себя, романтизируют образ «бородатого айтишника, ночами сидящего в Интернете и появляющегося в офисе только в день зарплаты» и стремятся попасть в когорту «бородатых». Стремление похвальное (тем более, что дефицит кадров на рынке весьма и весьма силен), но необоснованное. Поведаю о своем опыте и об опыте своих товарищей.

1. Слишком «гибкий» график работы.

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

 2. В низкой квалификации или глупости пользователей всегда будете виноваты вы.

Если пользователь не может найти кнопку включения питания на корпусе или удаленный им же самим документ на рабочем столе, то будьте готовы услышать в свой адрес фразу вроде: «Что вы опять там вытворяете?! Ничего не работает!» Причем, слова «опять» и «ничего» произносятся с особым нажимом, даже если речь идет о запавшей клавише на клавиатуре.

В своей практике сталкивался с несколькими особенно показательными случаями:

Случай №1: руководил отделом ИТ на крупном государственном предприятии. Было у нас одно конфликтное подразделение, к проблемам и потребностям которого руководство приказало относиться с особым вниманием. Звонит их руководитель, не своим голосом кричит: «У нас оргтехника ОПЯТЬ не работает!» Оргтехники у них было 6 единиц на 7 человек (функционал только одного цветного, лазерного МФУ формата А3 ничем не дублировался в пределах их двух кабинетов), т.е. более чем достаточно. Значит если «оргтехника не работает» — то действительно стряслось что-то серьезное. Безо всяких регистраций обращения, высылаю к ним системного администратора. Возвращается через полчаса (туда идти в один конец минут 5-7), загадочно улыбается, на вопросы не отвечает, говорит лишь, что все напишет в отчете. Написал. Читаю: «Из 6 единиц оргтехники, одно устройство жевало бумагу при копировании документов через автоподатчик. Разобрал устройство до основания, вытащил из механизма автоподатчика скрепку и смятую пищевую пленку, с помощью сжатого воздуха и спиртового раствора, удалил из(с) устройства сахарный песок (!!!!!) и засохшие липкие пятна (предположительно, пролитый кофе или напиток «Coca Cola»). Остальные 5 устройств, находящиеся в шаговой доступности, были исправны».

Cлучай №2: то же предприятие, но уже бухгалтерия. Период сдачи годовой отчетности, дедлайн — сегодня, бухгалтерия вся на нервах. Прибегает бухгалтер, состояние — близкое к истерике: «Компьютер весь мигает! А нам баланс сдавать сегодня!!! Вы нам работу срываете!!!!11адинадин» С ней выбегает администратор, устранять поломку. Возвращается через минуту, пишет тикет в HelpDesk: «Инцидент: мерцает монитор, система не отвечает на действия пользователя. Решение: убрал папку с документами с клавиатуры».

Случай №3: коммерческое предприятие, западная система управления, англоязычный директор и его «звездная» секретарша. В 5-м часу утра пробуждаюсь от телефонного звонка, определитель намекает на «звезду». Снимаю трубку:

— Алло! Мой телефон не подключается к WiFi в гостинице!
— Ммм… вы знаете, который час?
— 9 утра! Я вообще-то в Тайланде.
— А я вообще-то в Москве… И вообще-то категорически не отвечаю ни за гостиничный WiFi в Тайланде, ни за ваш личный телефон.
— Шеф ждет важный отчет, который я не могу ему отправить! (это, стало быть, почти прямая угроза в мой адрес: дескать, если не поможешь, то не мне, а САМОМУ ШЕФУ!)
— Милая, повторяю: я понятия не имею, что там за гостиница, что там за WiFi, что там за Тайланд и даже что там у вас за телефон, да еще и с важным отчетом. Если так срочно нужно выйти в Интернет, то зайдите в Интернет-кафе.
— Я этого так не оставлю! (короткие гудки)

Врала. Оставила.

Между вышеописанными случаями есть одна общая черта: крайним всегда будет ИТ-специалист. То есть вы, да. Готовьтесь, юные подованы.

 3. Относительно низкий уровень заработных плат.

Менеджер по продажам с окладом в 20 тыс. руб. за счет комиссионных будет получать 120, а еще квартальные и ежегодные премии, а еще карьерный рост, а еще уважение руководства, для которого он зарабатывает деньги. Вас же года через 3-4 после начала карьеры будет ждать зарплата в 60 тыс. руб. И все. Кадры не умеют измерять KPI ИТ-специалистов, а значит премий и прибавок ждать неоткуда. Комиссионные системным администраторам не платят. А руководство и вовсе видит в ИТ центр затрат. Поэтому через эти самые 3-4 года вышедший с вами в один день на работу менеджер по продажам будет ездить на Тойоте и питаться в «Гудмане», а вы будете ездить на метро и кушать шаверму.

 4. «Низкий потолок».

Из системных администраторов получаются старшие системные администраторы, инженеры, архитекторы, начальники отделов ИТ и директора по ИТ. Более-менее вкусные должности – две последние, да и то только в том случае, если вам удастся пристроиться в крупную компанию со зрелым топ-менеджментом, способным ценить вклад ИТ в бизнес. Технические же позиции имеют крайне низкий потолок заработных плат (на сегодняшний день в Москве это около 120 тыс. руб., даже если вы получите CCNP и/или пару MCITP). Исключения, конечно, есть, но они – исключения. С точки зрения престижа все еще хуже: ИТ-специалисты — это обслуживающий персонал, ни больше, ни меньше. Т.е. их можно ставить в один ряд с официантами, барменами, гардеробщиками и, например, дворниками. Это, конечно, замечательные профессии, но все-таки не очень престижные и не очень высокооплачиваемые. Поэтому большая часть амбициозных людей из ИТ все же со временем уходит (причем чаще всего в бизнес).

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

Будете, никуда не денетесь. По крайней мере, какое-то время. По этому поводу есть старый советский анекдот:

Проститутка приехала в Ялту на отдых. Купается, загорает, кушает фрукты… в общем, вкушает райский отпуск. Положил на нее глаз мужичонка, подошел познакомиться и предложить свою компанию с вытекающей из этого интимной близостью.
— Мужик, вот ты кем работаешь? – спрашивает проститутка
— Слесарем.
— Вот представь: приезжаешь ты на юг в отпуск, а вокруг станки, станки, станки…

С вами тоже так будет. Компьютеры надоедят, но заниматься ими придется и на отдыхе, т.к. коллеги и друзья, воспринимая вас как гуру, способного и желающего помочь, постоянно будут подсовывать вам свои ноутбуки, компьютеры, роутеры и даже мобильные телефоны с просьбами решить их проблемы. Кто-то довольно быстро обзаводится броней «Простите, нет времени. И в ближайшие пару лет не предвидится». А кто-то годами водит хороводы вокруг своих знакомых и их однотипных проблем. Я, например, отказывать коллегам научился довольно быстро, но до сих пор помогаю друзьям и родственникам. Без радости, как вы понимаете.

6. Не факт, что вам достанется интересная работа.

Чаще всего ИТ-персонал бывает занят поддержкой старых технологий и сервисов. Рутина, рутина, рутина, рутина, рутина…

Поработать в ИТ все еще кажется вам хорошей идеей?

Default ,

ИТ-проекты: национальный подход

27 февраля 2011

В Этой-Удивительной-Стране почему-то принято либо ничего не делать, либо делать через самую что ни на есть задницу: ни с кем ничего не согласовывая, медленно, некачественно, неэффективно и согласно собственным убеждениям (в то время как давно придуманы и используются отраслевые стандарты). Особенно заметно это проявляется в части ИТ, когда на предприятии сидит во главе департамента типовой кандидат на получение справки о врожденном идиотизме, и, собственно, всячески изгаляется на производственной среде, постоянно чего-то выдумывая и внедряя. Таких, к несчастью, много, а т.к. свои эксперименты они проводят «на живую», бизнес, пригревший их по недогляду, ощутимо страдает.

Вступление не без намека на реальную ситуацию. Теперь «тело» истории, внимайте: территориально распределенное торговое предприятие. Головной офис в СПб, филиалы в Москве, Казани и еще черт знает где общим числом 8 штук. Количество сотрудников (с компьютерами) — под 4 сотни. ИТ-инфраструктура, мягко говоря, не очень. Где-то Windows и AD, где-то Linux с Samba и Squid, а где-то и вовсе роутер для домашнего использования и 5 ноутбуков, выходящих через него в Интернет. Между Москвой и СПб — какой-никакой, но VPN, хотя домены AD разные, да без всяких изысков вроде доверительных отношений и общей ИТ-инфраструктуры. Никаких стандартов, никаких процедур, никаких SLA и KPI (хотя KPI должны разрабатывать кадровики, ИТ-специалисты обязаны как минимум этому способствовать), никаких систем и регламентов. Ключевые сервисы — телефония (Panasonic), 1С (1С) и почта (хостинг-провайдер, cPanel и много-много вручную создаваемых и управляемых ящиков). 1С, кстати, на dedicated-сервере в датацентре. Business-critical, даже мудак у руля ДИТ это понимал и ответственность за существование 1С на себя не брал. Но вот с почтой было паскудно…

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

Так и тут: 400 почтовых ящиков, созданных в ПУ хостинг-провайдера, созданных без применения единого стандарта наименования. 400 логинов, 400 паролей. И таблица в Excel, в которой весь этот шлак кое-как задокументирован. Начальнику ДИТ это, конечно, шибко не нравилось, и он родил идею: внедряем, блядь, Exchange. Купил 2007-й Enterprise и стал внедрять.

Сперва Exchange не внедрился. Возникли какие-то ошибки установки, а перезапуск setup.com выдал месседж, что, мол, Exchange в инфраструктуре уже присутствует, а посему ставить новую копию уже как бы и незачем. Т.к. начальник ДИТ про Exchange имел весьма жидкие знания, он начал грешить на домен AD (глючит, мол). Ладно. Скоро сказка сказывается, не скоро дело делается. Переустановили AD в Питерском офисе. Запустили setup — Exchange встал. Epic, блядь, win. Ценой титанических усилий сисадминов, правда, но все-таки win. Дальше Exchange стали конфигурировать, и почта ходить перестала. Совсем. А компания торговая. Для торговой компании почта имеет ключевое значение. Счет-то, блядь, как отправить заказчику?! По факсу?! Отчет руководству как передать?!?! С личного ящика писать?!?! Актами сверки перед сдачей НДС как обменяться?!?!?! Курьерами?!?!?! В общем, апокалипсис.

Сферический мудак в вакууме

Начальник ДИТ не знал, что ящики в Exchange создаются для активных учетных записей пользователей в AD, а не для любого рандомного рыла на планете. Он не знал, что для отправки почты требуется настроенная внутренняя инфраструктура DNS (ну хотя бы MX-запись). Он не знал, что опубликовать OWA и OutlookAnywhere довольно сложно, если нет ISA Server. Он не знал, что для OutlookAnywhere требуется сервер сертификатов. Он не знал, что региональные DNS обновляются несколько дольше, чем Питерские и Московские, и что офис в Казани даже через 3 дня не знал о смене MX-записей на стороне провайдера. А потом узнал, и когда MX-записи вернули на место, Казань еще 3 дня пыталась слать почту через IP-адрес Exchange, который к тому моменту уже был выведен из эксплуатации.

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

Теперь кратко суть: начальник ДИТ провел разведку боем, настроив send/recieve-коннекторы в Exchange, опубликовав SMTP наружу и сразу же поменяв MX-записи у регистратора домена. То, что в таком режиме нихуя не заработает, он узнал лишь тогда, когда не заработало, и еще 2 дня силился сообразить, где он допустил ошибку, и истерично вносил изменения в разные компоненты Exchange, никоим образом к проблеме не относящиеся. А потом скомандовал «назад». Получил выговор, финансовое взыскание и ушел в отпуск приводить себя в тонус водкой.

Итого одной из основных проблем бизнеса в Этой-Удивительной-Стране являются клинические идиоты, способные пустить пыль в глаза костюмом хорошего покроя (купленного на откаты) и внушающей доверие риторикой (пиздобольством), и такие же идиоты в отделах кадров, запросто пропускающие собратьев по диагнозу на ключевые должности.

Default , , ,

О быстродействии сетей TCP/IP

15 января 2011

Консультативно решал проблему с низким быстродействием гигабитной сети на 200 хостов. Решил. Полуневменяемому заказчику (кстати, айтишнику) пришлось канонически обосновывать причины, по которым было выбрано решение. И в процессе предлагать статистику, доходчиво объясняющую, почему сети иногда тормозят. Формулирую еще раз, уже публично.

Быстродействие сетей TCP/IP обычно ограничивается следующими типами ошибок:

1. потери и повреждения пакетов;
2. перегрузка каналов связи;
3. плохое оборудование;
4. некорректная IP-маршрутизация, большое время двойного оборота;
5. недопустимые размеры пакетов;
6. неэффективные приложения.

Вопросов не вызвали, пожалуй, только пункты 3 (за исключением стандартного: “А чой-то оно плохое вдруг?!”) и 6 (за исключением такого же стандартного, мол: “А чой-то они неэффективные вдруг?!”). Но на то он и руководитель департамента ИТ со степенью MBA, чтобы ничего не смыслить в технике, но давать ценные указания по работе с ней. Перевел на человеческий язык, таки почему ж тормозят сети:

1. кривые руки сетевого администратора;
2. непредназначенное для работы в enterprise-среде оборудование (в т.ч. устаревшее морально и физически);
3. зоопарк вирусов в сети (слышал о бот-нетах на несколько тысяч хостов, рассылающих горы спама… какое уж там быстродействие);
4. кривое ПО (написанное девелопмент-студией из Вышнего Волочка в перерывах между парами в шараге и брошенное на произвол судьбы сразу же после подписания акта о выполненных работах и последующей оплаты);
5. неквалифицированный технический персонал в целом (вынес отдельно от пункта 1, поскольку сетевой администратор может быть и вменяемым, а вот системный может запускать многочасовое резервное копирование через коммутатор уровня доступа на слабосильный NAS в рабочее время).

Вышеупомянутый руководитель ДИТ все понял. Решение одобрил. Стало хорошо, даже с его точки зрения. Айс.

Default , , ,

RFCs

20 декабря 2010

Разрешаем Remote Desktop для непривилегированного пользователя на контроллере домена

26 мая 2010

По умолчанию, для контроллеров домена действует политика, запрещающая подключения к ним через RDP членам группы Remote Desktop Users, если они не входят в группу Domain Admins. При попытке подключения такого пользователя к DC, появляется сообщение: «To log on to this remote computer, you must be granted the Allow log on through Terminal Services right. By default, members of Remote Desktop Users group have this right. If you are not a member of the Remote Desktop Users group or another group tha has this right, or if the Remote Desktop User group does not have this right, you must be granted this right manually

Определенная логика в такой политике есть, но бывают ситуации, когда на DC развертываются службы, управляемые не доменными администраторами. И в этом случае возникает необходимость предоставить им возможность управления сервером с соответствующим делегированием полномочий. Как было упомянуто, добавление администраторов в группу Remote Desktop Users не срабатывает. Зато срабатывает следующее:

1. Открываем из меню Start -> Settings -> Control Panel -> Administrative Tools -> Terminal Services Configuration;
2. В разделе Connections открываем Properties соединения RDP-Tcp;
3. Во вкладке Permissions добавляем учетную запись, которой требуется доступ к серверу через Remote Desktop, и даем ей необходимые права (User Access, например):

4. Празднуем победу.

Default , ,

Книга рецептов системного администратора #2: инструментарий

27 апреля 2010

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

1. Ноутбук с WiFi, Ethernet, Bluetooth и COM-портом. В качестве программной начинки необходимы сниффер, telnet- и ssh-клиенты, TFTP-сервер, программный эмулятор терминала.

Ноутбук является главным инструментом в работе системного администратора. Мне он неоднократно требовался для тестирования каналов связи в интернет, настройки коммутаторов, маршрутизаторов, точек доступа, программирования АТС, решения проблем с сетями (низкая скорость работы, “непроходимость” пакетов через определенные узлы и пр.), конфигурирования серверов (Unix/Windows), лечения зараженных вредоносным ПО компьютеров и т. д.

Особенно важно его наличие в том случае, если системный администратор работает в аутсорсе, либо обслуживает, кроме одного офиса, еще и сеть филиалов.

И еще позаботьтесь о том, чтобы в ОС на вашем ноутбуке был DHCP-клиент в режиме расширенного вывода.

2. Сервер для экспериментов с различными ОС, ПО и конфигурациями.

“Разведка боем” в ИТ зачастую заканчивается плачевно. Поэтому большинство обновлений или новых технологий системный администратор предварительно обкатывает на тестовой машине, не рискуя работоспособностью сети и сервисов. Так как большинство экспериментов системный администратор проводит с наиболее свежими версиями ПО, зачастую требовательными к аппаратному обеспечению, что автоматически исключает возможность использовать старые, снятые с эксплуатации, маломощные серверы. Однако для таких серверов нет строгих требований к инфраструктуре: скажем, нет необходимости подключать его к отдельному ИБП или монтировать в стойку (а оборудование в рэковом исполнении обычно существенно дороже), что снижает их стоимость. Небольшая стоимость в комплексе с необходимостью поддерживать сервисы на должном, современном уровне, чаще всего дает положительную оценку коммерческой целесообразности приобретения сервера для экспериментов.

3. Последовательный кабель, USB-кабель (A<->B) длиной 3 метра, патч-корды разной длины, в числе которых обязательно 2-3 длинных, по 30-50 метров.

4. КПК или бумажный органайзер.

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

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

5. Портативный жесткий диск.

6. Док-станция для жестких дисков с интерфейсами SATAII/IDE.

Не самое распространенное до недавнего времени устройство, док-станция уже стала настоящей палочкой-выручалочкой для многих системных администраторов. Она совершенно незаменима для переноса данных (например, при замене ПК пользователя или с сервера на сервер), лечения вирусов и подготовки типовых образов ОС и ПО. Пример можно посмотреть тут.

7. Набор отверток.

Отвертки должны быть качественные, с хорошими магнитными жалами, всех размеров и цветов, в большом количестве.

8. Устройства для зачистки, обжима, кроссировки кабеля и кабельный тестер.

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

9. Портативный принтер для ярлыков и наклеек.

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

10. Мобильный телефон с SIM-картой от оператора, обеспечивающего наилучший прием на рынке.

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

11. Рации.

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

12. Цифровой фотоаппарат.

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

13. Шкаф с инструментами и склад с комплектующими.

14. Библиотека с набором справочников по технологиям.

15. Аптечка с обезболивающими, йодом, раствором перекиси водорода, пластырем и бинтами.

16. Запас готовых продуктов питания долгосрочного хранения (печенье, шоколад, чипсы, маринованные огурцы или грибы, чай, кофе, сахар).

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

Книга рецептов системного администратора

Восстановление состояния объектов групповой политики по умолчанию

30 марта 2010

Случается, возникает необходимость восстановить исходное состояние политик для домена и для контроллеров домена (например, настроить все заново проще, чем перестроить после предыдущего системного администратора; либо возникают ошибки при применении GPO, а RSoP не выявляет ошибочно настроенную политику). Для этого существует программа dcgpofix.

При ее запуске, будут утеряны все изменения объектов групповой политики Default Domain Policy и Default Domain Controllers Policy (даже в том случае, если они были переименованы). Отдельно восстановить политики по умолчанию для домена или для контроллеров домена можно, используя ключ /target с указанием параметра dc или domain. Для использования dcgpofix в среде с различными версиями Active Directory, следует использовать ключ /ignoreschema.

Перейдем к примерам. Восстановим исходное состояние политики контроллеров домена в среде с разными версиями AD:

dcpgofix /ignoreschema /target: dc

Microsoft(R) Windows(R) Operating System Default Group Policy
Restore Utility v5.1

Copyright (C) Microsoft Corporation. 1981-2003

Description: Recreates the Default Group Policy Objects (GPOs)
for a domain

Syntax: DcGPOFix [/ignoreschema] [/Target: Domain | DC | BOTH]

This utility can restore either or both the Default Domain Policy or the
Default Domain Controllers Policy to the state that exists immediately
after a clean install. You must be a domain administrator to perform
this operation.

WARNING: YOU WILL LOSE ANY CHANGES YOU HAVE MADE TO
THESE GPOs. THIS UTILITY IS INTENDED ONLY FOR DISASTER
RECOVERY PURPOSES.

You are about to restore Default Domain controller policy for the
following domain lab.local
Do you want to continue: &lt;Y/N&gt;? y
WARNING: This operation will replace all 'User Rights Assignments' made
in the chosen GPOs. This may render some server applications to fail.
Do you want to continue: &lt;Y/N&gt;? y
The Default Domain Controller Policy was restored successfully
Note: Only the contents of the Default Domain Controller Policy was
restored. Group Policy links to this Group Policy Object were not altered.
By default, The Default Domain Controller Policy is linked to the Domain
Controllers OU.

Результат выполнения команды можно увидеть, запустив редактор объектов групповых политик и проверив «дефолтность» Default Domain Controllers Policy.

Default , ,

Этический кодекс системного администратора

29 марта 2010

Профессионализм

• Я буду соблюдать профессиональные нормы на рабочем месте и не позволю личным чувствам или убеждениям заставлять меня относиться к людям несправедливо или непрофессионально.

Личная сознательность

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

• Я буду по возможности избегать конфликтов интересов и убеждений. Когда у меня попросят совет и при этом имеется конфликт интересов и убеждений, я сообщу о последнем, если это уместно, и при необходимости откажусь от участия.

Неприкосновенность личной информации

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

Законы и политики

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

Общение

• Я стану обсуждать с руководством, пользователями и коллегами компьютерные вопросы, если это будет в наших общих интересах.

• Я буду стараться выслушать и понять потребности всех сторон.

Целостность системы

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

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

Образование

• Я буду улучшать и расширять свои технические знания и другие навыки, связанные с работой.

• Я буду делиться своими знаниями и опытом с другими.

Ответственность перед компьютерным сообществом

• Я буду сотрудничать с более крупным компьютерным сообществом, чтобы поддерживать целостность сетевых и компьютерных ресурсов.

Социальная ответственность

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

Нравственная ответственность

• Я постараюсь создать и поддерживать спокойную, здоровую и продуктивную рабочую обстановку.

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

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

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

(с) Интернет

Default ,

Регистрация сервисного контракта Cisco SmartNet

27 марта 2010

Даже специалисты службы технической поддержки Cisco признают, что по сайту Cisco нужно писать отдельный мануал. Я возьму на себя задачку попроще: напишу, как привязать сервисный контракт SmartNet к своей учетной записи на сайте Cisco. Такая привязка даст вам возможность получить доступ к определенным ресурсам сайта, для обычных пользователей недоступным.

Итак, начнем. Заходим на http://cisco.com, логинимся под своим аккаунтом и входим в его настройки, нажав “Account” в правом верхнем углу страницы:

01

Далее следуем в Profile Manager:

02

В меню сверху выбираем “Additional Access”:

03

Сообщаем, что у нас есть желание добавить номер сервисного контракта в профиль, нажатием следующей ссылки:

04

Ну и, наконец, вводим номер сервисного контракта в соответствующее поле и жмем “Submit”:

05

После этого вы автоматически попадете в Profile Manager, в котором появится такое уведомление:

06

Обычно сервисный контракт добавляется к вашему профилю в течении 2-3 часов. После того, как это случится, в Profile Manager появится следующее:

07

Теперь вы – полноценный Service Contract Owner.

Default , ,

Книга рецептов системного администратора #1: alias’ы в DNS как метод борьбы с потерей времени

25 марта 2010

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

Чтобы избежать таких проблем, составьте список сетевых ресурсов (например, почта, файловый сервер, сервер баз данных) и определите на них alias’ы (псевдонимы) в DNS. Например, псевдонимом для почтового сервера может послужить mail, для сервера баз данных — db, для файлового сервера — file. И при переносе какого-либо ресурса или сервиса на новый сервер, вам понадобится внести всего одно исправление в DNS (скажем, старый файл-сервер назывался fs1, новый вы назвали fs2; меняем значение alias’a file на fs2), и миграция сервиса произойдет абсолютно прозрачно для пользователей.

Книга рецептов системного администратора ,

Книга рецептов системного администратора: Disclaimer

25 марта 2010

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

Книга рецептов системного администратора ,

Запуск программ, требующих прав администратора, под учетной записью непривилегированного пользователя

21 марта 2010

Чтобы добиться работоспособности ПО, требующего для запуска права администратора, под учетной записью пользователя, можно воспользоваться следующим алгоритмом:

— Зайти в систему под учетной записью администратора.
— Установить на директорию с исполняемым файлом программы права на модификацию файлов и каталогов для нужного пользователя.
— Установить на ветки реестра HKLM\Software\Раздел-Нужной-Программы и HKCU\Software\Раздел-Нужной-Программы полные права для нужного пользователя.
— Экспортировать модифицированные ветви рееста в reg-файл.
— Зайти в систему под учетной записью пользователя.
— Импортировать ранее выгруженные файлы реестра.
— Перезагрузить компьютер.

Рецепт работает в 99.9% случаев.

Default ,

Случай из практики #1: “Плохой принтер!”

20 марта 2010

Пару лет назад подвернулась мне небольшая халтурка: организация принт- и файл-сервера и интернет-шлюза с биллингом в офисе на 10 человек. Офис, в основном, состоял из проектировщиков, втыкающих в мониторы с диагоналями от 30 дюймов и расходующих тонны бумаги и тонера с чернилами на печать своих произведений. Кроме сервера, попросили также купить им недорогой струйный принтер формата А3, на котором они могли бы в черновом варианте печатать свои проекты. Итак, работы окончены, акты подписаны, деньги переданы; довольные с заказчиком друг другом, тепло расстаемся.

Не далее как через неделю позвонили. Из трубки – мат-перемат, угрозы кровавой расправы и требования явиться сей момент пред очи звонящего. Что ж, явился. Демонстрируют: из вышеупомянутого принтера вылезают листы бумаги, на которых изображена… гнусная мазня. Пачкает принтер! Объясняю, что на такие случаи есть гарантийные документы на принтер, договорные отношения с поставщиком расходных материалов и прочие юридические факторы, способные призвать к ответу лиц ответственных, но принтер открываю и на взгляд диагностирую. Поизвлекал и осмотрел картриджи, поводил внутри салфеткой (для уверенности, что чернила не протекли в механизм протяжки бумаги), на всякий случай запустил очистку сопел… мазня! Беру в руку лист и поражаюсь: чистый гибрид туалетной бумаги и кальки! Тонкая и мягкая. Удивительно, где вообще такую отыскали. Спрашиваю, есть ли нормальная бумага. Есть, но в дефиците. Дают один листочек. Запускаю документ на печать – на выходе отпечаток идеального качества. Показываю заказчику, объясняю, что от типа бумаги вид отпечатанных документов зависит не меньше, чем от качества принтера. И что на их бумаге капля чернил из сопла картриджа просто растекается по окружности, в то время как должна оставаться на месте. Консенсус достигнут, напутствую не экономить деньги в ущерб качеству и нервам, по-доброму прощаемся, уже навсегда.

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

Случай из практики ,

Jabber-сервер для локальной сети. Openfire + MySQL под Windows

3 октября 2009

Почти в каждом офисе, насчитывающем 30 и более сотрудников, рано или поздно возникает необходимость реализовать систему мгновенного обмена сообщениями. Причем, желательно со списком контактов, хранящимся централизованно, на сервере, структурированном по отделам, с сохранением истории сообщений, удобным русскоязычным интерфейсом и прочими рюшечками, которые так ценит руководство. Что ж, это задача не из числа неподъемных. Я расскажу как ее реализовать на базе связки jabber-сервера Openfire и СУБД MySQL под управлением Windows.

Нам нужна выделенная машина с Windows (версии XP и старше), дистрибутивы Openfire и MySQL. Начнем с установки и настройки MySQL.

Читать далее…

How-To , , , , ,

Press any key…

8 сентября 2009

Летом у нас был практикант. Учился, набирался, так сказать, сеансу, эникейского формата. Под занавес его карьеры, поручил записать ему 5 комплектов дисков с Windows Server 2003. Показал сервер с iso’шниками, дал болванок, показал на ярлычок с UltraISO и скомандовал приступить к выполнению. Сегодня пришла пора воспользоваться результатами его трудов. Пихаю диск в сервер – не грузится. Перезагружаюсь, проверяю Boot Priority в BIOS, убеждаюсь, что 1-м пунктом стоит оптический привод, перезагружаюсь еще раз… не грузится. Пробрало любопытство, посмотрел содержимое диска у себя на компьютере. Мы плакали всем отделом:

anykey

Default ,

WSUS 3.0 SP2: что нового?

1 сентября 2009

Пришла осень, и скоро официально выйдет Windows Server 2008 R2 и Windows 7. Корпоративная сеть к внедрению инновационных продуктов почти готова, дорисовываю последние штрихи. В частности, установил сегодня SP2 для WSUS. Скорее, из праздного любопытства. Необходимость в этом не возникнет, по крайней мере, еще месяца 3. Итак, чего несет в себе SP2?

1. Обеспечивает поддержку клиентов Windows 7.

2. Обеспечивает поддержку BranchCache на Windows Server 2008 R2.

Дело за малым: внедрить Windows 7 и Windows Server 2008 R2, а также развернуть службу Branch Cache. (:

Default , ,