Comments 89
Всё хорошо, только зачем эти бесполезные картинки, которые только отвлекают?
Вашими бы устами, да мёд пить.
А в чем проблема? Просто не надо за раз все делать. Надо постепенно подходить и поставить процесс. Наметить себе важные для Вас цели и потихоньку и не спеша, но ежедневно\ежемесячно\ежеквартально\ежегодно их достигать! Как говорят «Дорога в тысячу ли начинается с одного шага»
Да нет, написано-то всё хорошо. И даже многое бы я взял на заметку с точки зрения того, каким языком можно доносить до руководства необходимость ухода от унаследованной разрозненной инфраструктуры. Потому что все более-менее опытные админы с комплексным подходом к решению задач всё вышеизложенное понимают чуть более, чем хорошо. Другое дело, что описана скорее теория из разряда «как должно быть» вместо «success story». Потому что на практике скорее будет, что директору на уши присядут 10 сотрудников недовольных «нововведениями» и все благородные планы админа по «наведению порядка» так и останутся планами. Либо он идет против всех, рвя рубаху на груди за правое дело, либо вспоминает, что у него дома жена и дети и плывёт по течению — «а не буду-ка я ни с кем спорить… да как бы меня не уволили еще… а что я тогда кушать буду...». В своей жизни я больше встречал людей второго типа, чем первого, поэтому и говорю, что написано-то всё красиво и правильно, но между этим планом и реальностью часто большая пропасть для преодоления которой мало только говорить, нужно еще и делать.
>>что директору на уши присядут 10 сотрудников недовольных «нововведениями» и все благородные планы админа
А кто отменил человеческое общение? Ведь не зря во многих вакансиях пишут «коммуникабельность». Все проблемы, если они есть их надо решать сообща! В среде программистов принято применять «рефакторинги». Этот же процесс можно применять и по отношению к любому процессу. Маленькие, небольшие, едва заметные сейчас улучшения могут привести к достаточно комфортным условиям работы потом! Не надо брать быка за рога сейчас, надо просто написать одно небольшое правило сейчас и улучшить его завтра если оно кому-то стало не особо понятно или в тягость.
А кто отменил человеческое общение? Ведь не зря во многих вакансиях пишут «коммуникабельность». Все проблемы, если они есть их надо решать сообща! В среде программистов принято применять «рефакторинги». Этот же процесс можно применять и по отношению к любому процессу. Маленькие, небольшие, едва заметные сейчас улучшения могут привести к достаточно комфортным условиям работы потом! Не надо брать быка за рога сейчас, надо просто написать одно небольшое правило сейчас и улучшить его завтра если оно кому-то стало не особо понятно или в тягость.
UFO just landed and posted this here
Извините, но именно с таким подходом я живу уже давным давно. Когда-то студентом довел свою сессию до такого состояния, что пришлось за 1 неделю и зачоты и курсовые и экзамены и еще много чего делать. С тех пор решил, что аврального темпа мне не надо и начал приучаться к ровному методу работы, когда одно маленькое действие сейчас, через час, через два и это значительно лучше чем «Ааа, как все это сделать?» потом! ;) Это как курить бросать, берешь и не куришь! Я бросил с 1 раза в 3.06.2002 хотя курил 6 лет и пачка петра 1 крепких уходила за день. Я к тому что если человек хочет, то он сделает, иначе найдет 100500 причин
Подход в разговоре с теми 10-ю сотрудниками должен быть такой: «ребят, вот вам удобно работать в текущем, неадекватном для меня, состоянии окружающего, давайте-ка чтобы и мне было удобно работать с вами в коллективе тут и тут поменяем.» И мыслить надо «в свой карман» а не для кого-то.
оффтоп: Пришел я как-то к хорошему знакомому менеджеру с которым раньше работал, говорю продай мне друже хороший ноутбук. он мне — запросто. выбирай!, и показывает прайс своего поставщика. ну я выбрал понравившееся. он говорит ОК, прям при мне плюсует 10% к ценнику и конвертирует сумму из баксов в рубли. вот мол, с тебя столько денег. я ему — а что за проценты?.. Ответ меня ошарашил своей неосознанной правильностью — «Ну я ведь должен что-то заработать!»
я это к чему. Не стесняйтесь показывать свою материальную заинтересованность в труде, это не просто нормально! это правильно, я на работе уже давно все делаю не для кого-то а «как для себя за деньги»
оффтоп: Пришел я как-то к хорошему знакомому менеджеру с которым раньше работал, говорю продай мне друже хороший ноутбук. он мне — запросто. выбирай!, и показывает прайс своего поставщика. ну я выбрал понравившееся. он говорит ОК, прям при мне плюсует 10% к ценнику и конвертирует сумму из баксов в рубли. вот мол, с тебя столько денег. я ему — а что за проценты?.. Ответ меня ошарашил своей неосознанной правильностью — «Ну я ведь должен что-то заработать!»
я это к чему. Не стесняйтесь показывать свою материальную заинтересованность в труде, это не просто нормально! это правильно, я на работе уже давно все делаю не для кого-то а «как для себя за деньги»
Вообще-то в посте практически все пункты про взаимодействие с руководством компании — так что о каких 10 сотрудниках вы говорите? Единственный пункт про взаимодействие с пользователями — 10-ый, и, возможно, частично 11-ый.
В 10-ом просто говорится, что попробуйте найти общий язык с пользователями и нормально выстроить взаимодействие по рабочим задачам. Если пользователи категорически не хотят нововведений — это тоже вариант построения рабочего взаимодействия.
В 11-ом, по-хорошему, почти все пользователи теряли данные, и хорошо понимают последствия — поэтому именно здесь проблем не должно быть даже у застенчивого косноязычного заикающегося красноглазика.
В 10-ом просто говорится, что попробуйте найти общий язык с пользователями и нормально выстроить взаимодействие по рабочим задачам. Если пользователи категорически не хотят нововведений — это тоже вариант построения рабочего взаимодействия.
В 11-ом, по-хорошему, почти все пользователи теряли данные, и хорошо понимают последствия — поэтому именно здесь проблем не должно быть даже у застенчивого косноязычного заикающегося красноглазика.
С точки зрения руководства, с которым ты разговариваешь, есть 10 человек, которых всё устраивает (саботажники), и есть 1 человек, которого не устраивает (собственно админ). Аргументы должны быть настолько железо-бетонными, чтобы 1 человек мог противопоставить своё мнение мнению большинства, чтобы в результате все сделали именно так, как он говорит. Речь в основном об этом. На практике количество людей напрямую заинтересованных в том, чтобы все осталось так как есть (недальновидная стратегия серых масс) перевешивает мнение одинокого воина.
В случае если обсуждаемый вопрос находится в вашей компетенции как системного администратора и не находится в компетенции остальных 10 сотрудников — ваше мнение по сути единственно важное.
Если же руководство компании считает, что мнение пользователей о том, как вам делать свою работу, куда важнее, чем мнение компетентного специалиста(вас) — то не совсем понятно с какой целью они вас вообще нанимали и может быть стоит поискать другую работу?
Если же руководство компании считает, что мнение пользователей о том, как вам делать свою работу, куда важнее, чем мнение компетентного специалиста(вас) — то не совсем понятно с какой целью они вас вообще нанимали и может быть стоит поискать другую работу?
Я хорошо понимаю и участвовал вживую в подобной ситуации. И мой опыт говорит однозначно, что здесь ваша терминология не соответствует реальности. То есть, любой такой глобальный конфликт админов с сотрудниками говорит о неумении админа договариваться, искать компромиссы и точки для приложения усилий — то есть, непрофессионал как менеджер (а бытиё менеджером навязывает зона ответственности). Да, большинство пользователей — идиоты, они не хотят учиться и что-то менять в своей жизни и рабочем процессе — это нормально и с этим нужно уметь работать, если считаешь себя профессионалом — как минимум на уровне «донести, зачем это нужно конкретному пользователю», «вписаться в существующие требования, если это возможно», и «в особо болезненных случаях найти выход в аккуратном самостоятельном эскалировании конфликта».
Нелогично. Если я админ, то я админ, а не менедждер. Я знаю как работают протоколы и умею настраивать компьютеры. Если бы я хотел быть менеджером, я не пошёл бы админить.
Рассматривая иерархию IT подразделения компании: выше вас есть кто-нибудь? Если нет, и вы подчиняетесь напрямую человеку, не работающему в IT подразделении, то вы — в том числе менеджер, иначе не бывает.
Если хотите вообще никогда не контактировать с людьми вне IT подразделения, или хотя бы общаться с ними только формализованно и на основании конкретных заявок — идите в крупные компании.
Если хотите вообще никогда не контактировать с людьми вне IT подразделения, или хотя бы общаться с ними только формализованно и на основании конкретных заявок — идите в крупные компании.
Конечно, админ а не менеджер, по ЗП же видно :)
Если серьёзно, то это не слишком правильно, когда берут эникейщика и требуют как с it-директора, но такова жизнь. И если вам не хватает амбиций или совсем другие цели — идти работать в такие условия несколько нелогично.
Если серьёзно, то это не слишком правильно, когда берут эникейщика и требуют как с it-директора, но такова жизнь. И если вам не хватает амбиций или совсем другие цели — идти работать в такие условия несколько нелогично.
Задача админа не договариваться с сотрудниками, а договариваться с руководителем. Если заручились поддержкой руководства (не менеджера конкретного отдела, а самого главного в данном подразделении) и 10 и 20 и 50 недовольных сотрудников идут лесом и высказывают свое недовольство руководителю. К сожалению приходилось столкнуться во время ввода режима коммерческой тайны на предприятии, встал перед выбором стараться понравиться всем или хорошо сделать свою работу, выбрал второе, да я стал на некоторое время врагом номер один всех любителей соцсетей, пасьянсов и таскателей флешек, но при полной поддержке руководства сделал свою работу, после чего успешно прошли сертификацию и уже через пару месяцев все привыкли к новым правилам и не понимали что могло быть иначе. Если системный администратор сам ставит себя не мальчиком на побегушках, от бухгалтерии к секретарю, а компетентным IT специалистом, тем более единственным на фирме, с его мнением считается руководство в первую очередь при принятии решений в сфере IT, но тут нужно не бояться всю ответственность брать на себя, а не перекладывать на менеджеров, закупку и прочих — это окупается.
Как вы хорошо сказали про зоопарк технологий. А то клиенты думают, что ты и картридж заправишь, и в 1с напрограмячишь, и скриптик на VB для экселя напишешь, и сайт забобахаешь (с дизайном, вёрсткой, программированием и продвижением), ещё закажешь, купишь, оплатишь, привезёшь и запустишь технику. И где-то между делом отказоустойчивый почтовый сервер поднимешь (естественно внутри организации, Яндексу-то мы не доверяем). Столько лкбеза приходится проводить, хорошо если понимают.
Тут должен был быть комментарий про вакансию водителя с опытом участия в формуле 1 и тд. Но мне лень его искать))
Поэтому доводить надо до людей.
Приводить разношёрстный парк к некоторому логическому единообразию, чтобы, если нет опыта/возможности самому администрировать эту логическую часть, можно было убедить в найме ещё одного специалиста именно по этой части, либо аккуратно переводить эту часть на те технологии, которыми достаточно хорошо владеете.
Оставлять как есть — это до первых проблем. Потом либо самому голову пеплом посыпать и пытаться быстро освоить незнакомую шайтан-технологию, либо привлекать кого придётся. К слову о планах аварийного восстановления.
Но, так или иначе, доводить до людей надо. И требовать, в случае сопротивления предметных объяснений, выходящих за рамки «ну оно же так работало» и «у нас так всегда было принято», почему не стоит менять платформы и стоит продолжать работать, следуя фразе «у нас так всегда было».
Приводить разношёрстный парк к некоторому логическому единообразию, чтобы, если нет опыта/возможности самому администрировать эту логическую часть, можно было убедить в найме ещё одного специалиста именно по этой части, либо аккуратно переводить эту часть на те технологии, которыми достаточно хорошо владеете.
Оставлять как есть — это до первых проблем. Потом либо самому голову пеплом посыпать и пытаться быстро освоить незнакомую шайтан-технологию, либо привлекать кого придётся. К слову о планах аварийного восстановления.
Но, так или иначе, доводить до людей надо. И требовать, в случае сопротивления предметных объяснений, выходящих за рамки «ну оно же так работало» и «у нас так всегда было принято», почему не стоит менять платформы и стоит продолжать работать, следуя фразе «у нас так всегда было».
А нет ли какого-нибудь стандартного набора документации, шаблона, который можно было бы заполнить? Приходя в новую компанию, мне всегда хотелось получить хорошо документированное описание всего, что там есть. Обычно получая треть от ожидаемого, появлялось желание самому все проинспектировать и задокументировать. То что получалось, было больше для личного пользователя и на солидный документ явно не тянуло.
Наверняка ведь есть какой-нибудь стандарт для всего этого.
Наверняка ведь есть какой-нибудь стандарт для всего этого.
Тоже интересно насчёт стандарта.
Следую такому же пути. Всё железо, ПО, используемые технологии, конфиги, бэкапы, время ресурсоёмких операций и т.д. — задокументировал в своё время. Периодически пользуюсь. Значит не зря. Периодически гоняю весь отдел по очереди на обновление всего списка, чтобы тоже приобщены были. По всё это на уровне таблиц, списков и того, как вижу я. Стандарт было бы интересно посмотреть, при наличии такового
Следую такому же пути. Всё железо, ПО, используемые технологии, конфиги, бэкапы, время ресурсоёмких операций и т.д. — задокументировал в своё время. Периодически пользуюсь. Значит не зря. Периодически гоняю весь отдел по очереди на обновление всего списка, чтобы тоже приобщены были. По всё это на уровне таблиц, списков и того, как вижу я. Стандарт было бы интересно посмотреть, при наличии такового
Тоже конечно интересно, только думаю стандарт пишут не админы. И потому его реализация будет просто сухим сборником спецификаций и объяснений для чего в организации например предназначен почтовый сервер.
Мне досталось куча документов в разных программах в которых периодически приходилось рыть по очереди для поиска нужного. Я вышел из положения поднятием внутренней вики и веду документацию там. Можно и расписать все по категориям, и исходники скриптов с удобной подсветкой вставить. Ну и все в одном месте всяко удобнее.
Мне досталось куча документов в разных программах в которых периодически приходилось рыть по очереди для поиска нужного. Я вышел из положения поднятием внутренней вики и веду документацию там. Можно и расписать все по категориям, и исходники скриптов с удобной подсветкой вставить. Ну и все в одном месте всяко удобнее.
Стандарт на документацию нужен для того, чтобы не потеряться в этой самой документации, уметь в ней быстро найти нужную информацию и легко разделять доступ к этой самой информации. Стандарт на ведение документации у вас возникнет сам собой, как только вы начнете эту информацию собирать и классифицировать. Какой-то универсальный стандарт не даст вам скорее всего ничего — вы его просто не оцените и он будет скорее для вас лишним препятствием при сборе информации.
То, о чем вы говорите — это скорее всего чек-лист для сбора данных по оборудованию/ПО/сервисам. Такие у нас в компании есть, но они не для общего пользования.
То, о чем вы говорите — это скорее всего чек-лист для сбора данных по оборудованию/ПО/сервисам. Такие у нас в компании есть, но они не для общего пользования.
Вы описываете работу в маленькой компании (с соответствующими навыками, ессно), но с подходом как в крупной. И даже в крупной такие вещи как вы описываете часто невозможны.
Самый смак начнется, когда проблема все равно возникает, ее можно условно назвать «DROP DATABASE». И выглядеть будет такой админ довольно жалко, с одной стороны он только что пальцы гнул, требуя не звонить по вечерам, а с другой положил работу организации.
В общем статья скорее о сферическом админе в вакууме: профессиональный, четкий, современный, коммуникабельный, сообразительный и, видимо, получающий маленькие деньги, раз может гнуть пальцы по поводу своего расписания и атаковать бумагами и определениями… в компании на 30 хостов.
Самый смак начнется, когда проблема все равно возникает, ее можно условно назвать «DROP DATABASE». И выглядеть будет такой админ довольно жалко, с одной стороны он только что пальцы гнул, требуя не звонить по вечерам, а с другой положил работу организации.
В общем статья скорее о сферическом админе в вакууме: профессиональный, четкий, современный, коммуникабельный, сообразительный и, видимо, получающий маленькие деньги, раз может гнуть пальцы по поводу своего расписания и атаковать бумагами и определениями… в компании на 30 хостов.
Статья о нормальном системном администрировании в любой компании на 30, 300 или 3000 хостов.
Все должно быть рассчитано, запланировано, задокументировано, зарезервировано и оговорено письменно, документация должна быть актуальна, резервное копирование должно выполняться автоматически, тесты резервных копий, в идеале, тоже с отчетом админу о результатах на почту и естественно непосредственное начальство должно быть в курсе любых изменений, происходящих в инфраструктуре. Причем администратор должен уметь объяснить нормальным «человеческим» языком, зачем эти изменения нужны, что конкретно они изменят и что может случиться, если изменений не производить.
Если у системного администратора все это есть — вряд ли он будет выглядеть жалко, потому что он точно знает, что делать когда происходит какая-либо нештатная ситуация.
А невозможных вещей не бывает — бывает лень, безалаберность и похуизм.
Все должно быть рассчитано, запланировано, задокументировано, зарезервировано и оговорено письменно, документация должна быть актуальна, резервное копирование должно выполняться автоматически, тесты резервных копий, в идеале, тоже с отчетом админу о результатах на почту и естественно непосредственное начальство должно быть в курсе любых изменений, происходящих в инфраструктуре. Причем администратор должен уметь объяснить нормальным «человеческим» языком, зачем эти изменения нужны, что конкретно они изменят и что может случиться, если изменений не производить.
Если у системного администратора все это есть — вряд ли он будет выглядеть жалко, потому что он точно знает, что делать когда происходит какая-либо нештатная ситуация.
А невозможных вещей не бывает — бывает лень, безалаберность и похуизм.
Реалии накладывают свои коррективы. Конечно, нужно, что бы все было и задокументировано и забэкаплено и план восстановления и все такое.
А каждый админ мечатет о том, о чем написана статья. Однако, повторюсь, в реальности просто бывает невозможно многое выполнить. Т.к. речь идет все-таки о небольшой компании (это потому что тут рассматривается работа одного человека самого себе подчиненного). И я бы не стал все это проецировать на 3000 хостов. Там другие правила игры.
А каждый админ мечатет о том, о чем написана статья. Однако, повторюсь, в реальности просто бывает невозможно многое выполнить. Т.к. речь идет все-таки о небольшой компании (это потому что тут рассматривается работа одного человека самого себе подчиненного). И я бы не стал все это проецировать на 3000 хостов. Там другие правила игры.
Резервные копии баз у него есть и схема резервного копирования согласована, план аварийного восстановления у него также есть и что делать он знает. С чего ему выглядеть жалко то?
И почему принято считать, что человек, который требует к себе отношения в рамках трудового законодательство (т.е. имеет право на труд и право на отдых) «гнет пальцы», если этот человек системный администратор?
И почему принято считать, что человек, который требует к себе отношения в рамках трудового законодательство (т.е. имеет право на труд и право на отдых) «гнет пальцы», если этот человек системный администратор?
Вы говорите про итальянскую забастовку. В теории, конечно, все идеально. Админ, конечно, хочет выглядеть важной птицей и прикрыть свою попу от неприятностей. Однако руководитель в такой ситуации обычно — директор компании или ближний по лестнице директор. Он обычно не очень хорошо понимает что такое бэкапы и документация. Он не очень понимает для чего нужен raid контроллер за 15 тысяч, когда вы только что ему объясняли про бэкапы и ежедневное резервирование. Он плохо понимает почему сервер может сломаться и может вполне связать это с вашей плохой работой, он обязательно приведет пример со своим домашним компьютером, который работает с 2000-го года.
В общем вот это документирование своей ответственности перед руководством, план бэкапа, зону ответственности, план работ и все такое обычно неприменимо в типичных Российских компаниях. А в крупных, с хорошим менеджментом, вам сами скажут что и как делать. Там не будет времени придумывать то о чем написано в статье, там будут свои штатные инструкции.
Но, однако, больше всего меня порадовал первый пункт. Если прийти к работодателю и начать разговаривать в таком тоне — это верный признак уйти домой без работы.
Я бы с большем удовольствием прочитал статью, где рассказывается как сделать из хаоса конфетку. Именно сам процесс. Любая компания это обычно устоявшийся бизнес-процесс, который довольно тяжело сдвигать даже в правильное русло. И вот этот процесс обычно довольно сложен. Когда из постоянных даунтаймов, кабельного хаоса, самосборных серверов компания модернизируется в современный дата-центр, который получил высокую надежность, энергоэффективность, скорость, новые сервисы, которые начали приносить свою пользу организации, выливающуюся в конкурентное преимущество. А в этой статье я увидел мечты админа. Я иногда тоже мечтаю что бы так было, однако когда возвращаюсь на работу, мои мечты разбиваются о суровую реальность :)
В общем вот это документирование своей ответственности перед руководством, план бэкапа, зону ответственности, план работ и все такое обычно неприменимо в типичных Российских компаниях. А в крупных, с хорошим менеджментом, вам сами скажут что и как делать. Там не будет времени придумывать то о чем написано в статье, там будут свои штатные инструкции.
Но, однако, больше всего меня порадовал первый пункт. Если прийти к работодателю и начать разговаривать в таком тоне — это верный признак уйти домой без работы.
Я бы с большем удовольствием прочитал статью, где рассказывается как сделать из хаоса конфетку. Именно сам процесс. Любая компания это обычно устоявшийся бизнес-процесс, который довольно тяжело сдвигать даже в правильное русло. И вот этот процесс обычно довольно сложен. Когда из постоянных даунтаймов, кабельного хаоса, самосборных серверов компания модернизируется в современный дата-центр, который получил высокую надежность, энергоэффективность, скорость, новые сервисы, которые начали приносить свою пользу организации, выливающуюся в конкурентное преимущество. А в этой статье я увидел мечты админа. Я иногда тоже мечтаю что бы так было, однако когда возвращаюсь на работу, мои мечты разбиваются о суровую реальность :)
>>и все такое обычно неприменимо в типичных Российских компаниях
Применимо и применяется!
>> А в крупных, с хорошим менеджментом, вам сами скажут что и как делать.
А этот менеджмент сам по себе выстраивается? Вот так вот люди приходят как-нить с утра, а уже менеджмент хороший!
Применимо и применяется!
>> А в крупных, с хорошим менеджментом, вам сами скажут что и как делать.
А этот менеджмент сам по себе выстраивается? Вот так вот люди приходят как-нить с утра, а уже менеджмент хороший!
Не сам по себе. Но и далеко не такими статьями. В крупных организациях совсем иное мышление и во главу ставится безопасность компании, как экономическая, так и информационная. А в статье во главу ставится админ, которые защищает свои интересы.
>>Но и далеко не такими статьями
А что в ней такого прям не от мира сего?
>>А в статье во главу ставится админ, которые защищает свои интересы.
Далеко не так! Во главу ставится «роль администратора». Если действующему админу предложат лучшую ЗП в другой конторе, то новому нужно будет быстро влиться. Как это сделать? А делается просто: документирование каждого шага! Причем автор еще не описал задачи:
* Ведение документа о решении популярных проблемах
* Инструкции развертывания бэкапа
* Инструкции развертывания какого-либо продукта
и др.
Все это делается с помощью Wiki в почти любой современной компании. По крайней мере у нас в компании многое документируется. Шороховатости решаются на скрамах и др. встречах
А что в ней такого прям не от мира сего?
>>А в статье во главу ставится админ, которые защищает свои интересы.
Далеко не так! Во главу ставится «роль администратора». Если действующему админу предложат лучшую ЗП в другой конторе, то новому нужно будет быстро влиться. Как это сделать? А делается просто: документирование каждого шага! Причем автор еще не описал задачи:
* Ведение документа о решении популярных проблемах
* Инструкции развертывания бэкапа
* Инструкции развертывания какого-либо продукта
и др.
Все это делается с помощью Wiki в почти любой современной компании. По крайней мере у нас в компании многое документируется. Шороховатости решаются на скрамах и др. встречах
В крупных организациях с менеджментом компании общается ИТ-директор, с пользователями общается служба технической поддержки, а сисадмины занимаются своей непосредственной работой. В мелких же компаниях сисадмин и швец и жнец и на трубе дудец и такая работа загубила многих умных, образованных и влюбленных в свою профессию специалистов. Эту статью я написал действительно для того, чтобы эти штатные админы могли за себя профессионально постоять в неравной схватке с менеджментом и пользователями и не ушли в тот асоциальный тип поведения, который так воспевается в народном фольклоре.
Неистово плюсую за озвученные проблемы, с которыми РЕАЛЬНО сталкиваются люди, работающие в ИТ-сфере. Сам 3 года работаю на аутсорсе в компании из 100 человек, в которой хаос, разброд и шатания, начиная с руководства и заканчивая уборщицей — это в порядке нормы, а порядок и стандарты — сказки изумрудного города. Делать из говна конфетку это как раз то, чем я занимаюсь всё это время. Поэтому и говорю, что всё, о чем написано в статье, хороший roadmap для небольшой конторы, но он с треском проваливается, когда на месте есть админ-побегушка, которому надо семью кормить, отлизывая всем, кто попросит, вместо того, чтобы соблюдать какие-то стандарты, которые позволят сохранить свою работу завтра. Все живут одним днём, какое им дело до того, что будет через год. Никого не волнует. «Всё ведь и так работает». ))
Когда я слышу жалобы админов на то, что в Российских компаниях ИТ-инфраструктура сделана из «постоянных даунтаймов, кабельного хаоса, самосборных серверов » я всегда задаю один вопрос: господа админы, а кто в этих компаниях сделал такой хаос? Неужели это сами директора собрались и наколхозили себе ИТ-инфраструктуру из того что было под рукой, а потом позвали вас ее обслуживать?
Почему вы считаете, что как только вы на собеседовании начнете задавать профессиональные вопросы, то домой уйдете без работы? Потому что есть менее принципиальные системные администраторы, которые готовы колхозить что угодно? Но даже если так, то какой смысл держаться за такую работу где ваш профессионализм не цениться?
Почему вы считаете, что как только вы на собеседовании начнете задавать профессиональные вопросы, то домой уйдете без работы? Потому что есть менее принципиальные системные администраторы, которые готовы колхозить что угодно? Но даже если так, то какой смысл держаться за такую работу где ваш профессионализм не цениться?
Мы же не рассматриваем компанию, в которой ИТ это его непосредственная деятельность. В классической компании, которая занимается услугами, продажами, производством, ИТ это отдел, который записан в убытки. Он ничего не производит, он не привлекает клиентов, не завязан в производственном процессе. И руководитель должен быть достаточно опытным, что бы знать как этот отдел использовать в свою пользу, а не только как поддержка компьютеров для починки сломавшегося ворда.
Во многих организациях на столько плачевная ситуация в ИТ, что даунтайм важных сервисов на несколько часов допустимая ситуация. И что же вы предлагаете? Менять организации как перчатки? Пряма сразу с первых лет работы? Непозавидую трудовой, в которой каждый год смена работы. А еще и приходит такой парень, который уже 10 раз сменил работу за 10 лет и начинает что-то втирать про «не звонить после 22, с работы ухожу ровно в 18 всегда, в отпуске телефон выключаю».
Хороший админ, который претендует на руководителя должен не защищать свое место бумажками, а наоборот создавать документооборот таким образом, что бы защитить ИТ структуру от ИТ отдела, а не свое место. Вводить регламенты для своей же работы. В результате при расширении компании вы получите надежную структуру, работающую даже без руководителя и непосредственных пинков подчиненных админов.
Если админ хочет быть инженером, то ему все эти бумажки не очень нужны, ему нужно развиваться в техническом плане, в будущем планировать свое устройство в консалтинговую или интеграторскую компанию.
Во многих организациях на столько плачевная ситуация в ИТ, что даунтайм важных сервисов на несколько часов допустимая ситуация. И что же вы предлагаете? Менять организации как перчатки? Пряма сразу с первых лет работы? Непозавидую трудовой, в которой каждый год смена работы. А еще и приходит такой парень, который уже 10 раз сменил работу за 10 лет и начинает что-то втирать про «не звонить после 22, с работы ухожу ровно в 18 всегда, в отпуске телефон выключаю».
Хороший админ, который претендует на руководителя должен не защищать свое место бумажками, а наоборот создавать документооборот таким образом, что бы защитить ИТ структуру от ИТ отдела, а не свое место. Вводить регламенты для своей же работы. В результате при расширении компании вы получите надежную структуру, работающую даже без руководителя и непосредственных пинков подчиненных админов.
Если админ хочет быть инженером, то ему все эти бумажки не очень нужны, ему нужно развиваться в техническом плане, в будущем планировать свое устройство в консалтинговую или интеграторскую компанию.
По поводу того, кто сделал хаос. Этапы, через которые проходит любая развивающаяся компания, в целом типичны и одинаковы для всех. Поначалу штат сотрудников небольшой и предприятие сосредоточено на том, чтобы войти в рынок и закрепиться на нём. При этом на данном этапе вопросов о какой-либо ИТ-структуре не стоит в принципе. Планирование ресурсов отсутствует, на перспективу никто не загадывает. Задачи ставятся здесь и сейчас и должны выполняться сиюминутно. Всё делается на бегу. Когда своих сил не хватает, появляется потребность в «сисьадмине», который берет на себя сопровождение созданного юзерами зоопарка. Обычно зарплату такому админу ставят небольшую из-за ограниченного бюджета и приходят на неё студенты без какого-либо опыта и видения, как ит-сфера предприятия должна развиваться дальше.
В отсутствие опыта работы у исполнителя и бесконечного числа разношёрстных задач, которые валятся на неокрепший подростковый ум, еще не родившаяся ит-сфера предприятия начинает месяц за месяцем впитывать в себя токсины лоскуточных «наколенных» решений. Затем в один «прекрасный момент» один админ уходит и на его место приходит другой. Теперь перед ним стоит задача сопровождения унаследованной костыльной архитектуры, миграции и развитие имеющихся сервисов (а чаще их надо переделывать, потому как предшественник сделал всё для того, чтобы они оказались мертворожденными и на них уже ничего не построить). Вся ситуация усугубляется низким уровнем лояльности со стороны сотрудников к админу, как к представителю профессии. Со всем этим ему приходится бороться, устраиваясь на новое место. Еще год-два подобной «текучки» админов в конторе и ИТ-сфера превращается в нечто совершенно неуправляемое. То, что можно было сделать раньше за время t, сейчас уже требует времени t*3. Админ начинает тонуть в суппорте внедренных ранее решений, оказываясь неспособным повлиять на дальнейшее развитие событий. Ситуация в ИТ-сфере превращается из неуправляемой в кризисную. Если компания к этому времени каким-то образом смогла встать на ноги и заработать достаточно денег для решениях проблем, на которые раньше все закрывали глаза, то следующим шагом вероятнее всего станет привлечение в компанию высокооплачиваемых специалистов со стороны. Как ни смешно, но в отличие от предшественников, их будут слушать хотя бы уже только из-за того, что платят им большие деньги. ))
Кто виноват в таком развитии ситуации? Неграмотный админ — полбеды. Неграмотное руководство — катастрофа. В любом случае определением того, в каком направлении идёт развитие предприятия, в первую очередь занимается руководство, а не админ. Стать грамотным ИТ-директором в компании, которая родилась и развивалась в хаосе, дано далеко не всем.
В отсутствие опыта работы у исполнителя и бесконечного числа разношёрстных задач, которые валятся на неокрепший подростковый ум, еще не родившаяся ит-сфера предприятия начинает месяц за месяцем впитывать в себя токсины лоскуточных «наколенных» решений. Затем в один «прекрасный момент» один админ уходит и на его место приходит другой. Теперь перед ним стоит задача сопровождения унаследованной костыльной архитектуры, миграции и развитие имеющихся сервисов (а чаще их надо переделывать, потому как предшественник сделал всё для того, чтобы они оказались мертворожденными и на них уже ничего не построить). Вся ситуация усугубляется низким уровнем лояльности со стороны сотрудников к админу, как к представителю профессии. Со всем этим ему приходится бороться, устраиваясь на новое место. Еще год-два подобной «текучки» админов в конторе и ИТ-сфера превращается в нечто совершенно неуправляемое. То, что можно было сделать раньше за время t, сейчас уже требует времени t*3. Админ начинает тонуть в суппорте внедренных ранее решений, оказываясь неспособным повлиять на дальнейшее развитие событий. Ситуация в ИТ-сфере превращается из неуправляемой в кризисную. Если компания к этому времени каким-то образом смогла встать на ноги и заработать достаточно денег для решениях проблем, на которые раньше все закрывали глаза, то следующим шагом вероятнее всего станет привлечение в компанию высокооплачиваемых специалистов со стороны. Как ни смешно, но в отличие от предшественников, их будут слушать хотя бы уже только из-за того, что платят им большие деньги. ))
Кто виноват в таком развитии ситуации? Неграмотный админ — полбеды. Неграмотное руководство — катастрофа. В любом случае определением того, в каком направлении идёт развитие предприятия, в первую очередь занимается руководство, а не админ. Стать грамотным ИТ-директором в компании, которая родилась и развивалась в хаосе, дано далеко не всем.
paramobilus, я полностью согласен с вашим мнением и виденьем, но меня всегда интересовал вопрос что первично: курица или яйцо. Перевоспитать владельцев бизнесов мне, наверное, не под силу, но я считаю, что обязан попытаться донеси информацию о том, как надо (или как не надо) работать до ИТ-специалистов. Да, всегда будут колхозники-однодневки, которые готовы работать с нелицензионным ПО и делать костыльные решения, но чем больше будет появляется людей с профессиональным подходом, тем средняя температура в данной сфере будет смещать в более нормальное и цивилизованное русло.
>>сделать из хаоса конфетку
Разве много надо? При условии, конечно, что директор не самодур и думает о развитии компании.
1. Наводим порядок с проводами. Как именно — были уже статьи на хабре. Да, придется часть переложить, закупить материалы и остаться после рабочего дня.
2. Порядок на машинах пользователей. Я сторонник того, что в мелкой (на 10-15 человек) компаннии, винда ставится только тем, кому без нее не обойтись — буху и директору. Остальные и на линуксах посидят, не обломаются. Здесь наверняка будут вопли и стоны. Главное пережить и убедить директора в том, что это необходимо. В противном случае — раскошеливаем начальство на лицензию и антивирусы. После такого аргумента оно, обычно, быстро соглашается.
3. Закрываем интернет от всего, что мешает рабочему процессу. Либо не закрываем, но весьма ощутимо режем скорость. В обед и после рабочего дня фильтры снимаются.
4. Все что можно — выносим на сервер/сервера, в зависимости от бюджета. Про бекапы и обслуживание серверов в статье хорошо написано.
5. Всегда должно быть запасное оборудование. В случае чего — чтобы было можно все заменить в краткие сроки.
6. Ну и время. Я отвечаю на звонки с работы в любое время. Мало ли что. У нас много клиентов и поставщиков из другого часового пояса и кто-то вполне может работать ночью. Мне от 10-ти минут общения в 3 часа ночи не убудет, а в ответ — хорошее отношение.
7. Документация всех логинов и паролей у директора. А вдруг со мной что случится, или в отпуске что сломается? Пусть будет. А я прослежу чтобы хранилось не на бумажке.
И в конце — важный фактор победы над хаосом — это нормальные отношения с начальником. И понимание директором IT проблем в офисе. Если не понимает — нужно объяснять проще. Практика показывает что договориться можно обо всем. А если не получается- может и ну их нафик, таких твердолобых.
Разве много надо? При условии, конечно, что директор не самодур и думает о развитии компании.
1. Наводим порядок с проводами. Как именно — были уже статьи на хабре. Да, придется часть переложить, закупить материалы и остаться после рабочего дня.
2. Порядок на машинах пользователей. Я сторонник того, что в мелкой (на 10-15 человек) компаннии, винда ставится только тем, кому без нее не обойтись — буху и директору. Остальные и на линуксах посидят, не обломаются. Здесь наверняка будут вопли и стоны. Главное пережить и убедить директора в том, что это необходимо. В противном случае — раскошеливаем начальство на лицензию и антивирусы. После такого аргумента оно, обычно, быстро соглашается.
3. Закрываем интернет от всего, что мешает рабочему процессу. Либо не закрываем, но весьма ощутимо режем скорость. В обед и после рабочего дня фильтры снимаются.
4. Все что можно — выносим на сервер/сервера, в зависимости от бюджета. Про бекапы и обслуживание серверов в статье хорошо написано.
5. Всегда должно быть запасное оборудование. В случае чего — чтобы было можно все заменить в краткие сроки.
6. Ну и время. Я отвечаю на звонки с работы в любое время. Мало ли что. У нас много клиентов и поставщиков из другого часового пояса и кто-то вполне может работать ночью. Мне от 10-ти минут общения в 3 часа ночи не убудет, а в ответ — хорошее отношение.
7. Документация всех логинов и паролей у директора. А вдруг со мной что случится, или в отпуске что сломается? Пусть будет. А я прослежу чтобы хранилось не на бумажке.
И в конце — важный фактор победы над хаосом — это нормальные отношения с начальником. И понимание директором IT проблем в офисе. Если не понимает — нужно объяснять проще. Практика показывает что договориться можно обо всем. А если не получается- может и ну их нафик, таких твердолобых.
Это все по-капитански и почти все очевидно. Кроме линукса, конечно :))
Однако в целом в романтичный процесс становления на ноги, все может разбиться о суровую реальность.
Однако в целом в романтичный процесс становления на ноги, все может разбиться о суровую реальность.
Простите, возможно в силу своего малого опыта я многого не понимаю, не не могли бы вы пояснить что именно из перечисленного мной может разбиться о суровую реальность? Ну кроме того что админ — ленивая задница, которому ничего не интересно и он пришел в фирму посидеть для стажа.
Толерантность к проблемам часто перевешивает, когда в вопросе возникают деньги. Нужны свитчи L3? Нафиг, дорого, даже L2 дорого. Нужны ключи для 1С? Нафиг, ломаную ставь. Регламент, стандарты? Не, не слышал.
Руководство считает деньги. Если кабели можно организовать, то, например, убедить в маленькой компании купить стойку может быть уже проблемой.
Суть в том, что админа в небольшую компанию нанимают для того, что бы он в первую очередь присматривал за оборудованием, а не тратил новые деньги, инвестировал в безопасность и надежность. А маленькие компании к тому же очень терпимы к отказам оборудования и могут даже несколько дней просидеть без связи и компьютеров, просто на личных связях.
То есть что касается личной ответственности админа: быть доступным по телефону, держать оборудование в порядке и документации, это, конечно возможно бесплатно, а вот смена ОС, бэкапы, разделение служб, запасное оборудование, все это может быть проблемой. И приходится выкручиваться и ставить приоритеты, что важнее. В каждой компании все невероятно уникально и что для одной компании чрезвычайно важно, для другой все равно.
Руководство считает деньги. Если кабели можно организовать, то, например, убедить в маленькой компании купить стойку может быть уже проблемой.
Суть в том, что админа в небольшую компанию нанимают для того, что бы он в первую очередь присматривал за оборудованием, а не тратил новые деньги, инвестировал в безопасность и надежность. А маленькие компании к тому же очень терпимы к отказам оборудования и могут даже несколько дней просидеть без связи и компьютеров, просто на личных связях.
То есть что касается личной ответственности админа: быть доступным по телефону, держать оборудование в порядке и документации, это, конечно возможно бесплатно, а вот смена ОС, бэкапы, разделение служб, запасное оборудование, все это может быть проблемой. И приходится выкручиваться и ставить приоритеты, что важнее. В каждой компании все невероятно уникально и что для одной компании чрезвычайно важно, для другой все равно.
Ну вот так и надо определить в начале работы: организация в принципе переживёт пару дней без сети, и чтобы админу не капали на мозги, пока он будет эту сеть чинить.
>Нужны свитчи L3? Нафиг, дорого, даже L2 дорого. Нужны ключи для 1С? Нафиг, ломаную ставь. Регламент, стандарты?
Именно для этого и нужно постоянное крючкотворство. Простой в сети из-за поломки дешевого soho коммутатора? Достаем свои любимые бумажки, в которых написано, что вы просили закупить такое-то оборудование с таким-то обоснованием и что вам покупку зарезали по такой-то причине.
Если деньги перевешивают, то попробуйте посчитать во сколько обойдется потеря данных за последний квартал и сколько будет стоит 3 жестких и рэйд-контроллер.
> В каждой компании все невероятно уникально и что для одной компании чрезвычайно важно, для другой все равно.
После этих слов вообще непонятно, а с чем вы спорите тогда? Где-то простой в день не критичен, а где-то и пара часов уже «аля-улю». Вот в первом случае можно просто «присматривать», а во-втором нужно быть заранее готовым.
>купить стойку может быть уже проблемой
На стоечный сервер денег хватило, а на стойку нет. Какой еще пример приведете — по второму разу коннекторы заставляют использовать?
Именно для этого и нужно постоянное крючкотворство. Простой в сети из-за поломки дешевого soho коммутатора? Достаем свои любимые бумажки, в которых написано, что вы просили закупить такое-то оборудование с таким-то обоснованием и что вам покупку зарезали по такой-то причине.
Если деньги перевешивают, то попробуйте посчитать во сколько обойдется потеря данных за последний квартал и сколько будет стоит 3 жестких и рэйд-контроллер.
> В каждой компании все невероятно уникально и что для одной компании чрезвычайно важно, для другой все равно.
После этих слов вообще непонятно, а с чем вы спорите тогда? Где-то простой в день не критичен, а где-то и пара часов уже «аля-улю». Вот в первом случае можно просто «присматривать», а во-втором нужно быть заранее готовым.
>купить стойку может быть уже проблемой
На стоечный сервер денег хватило, а на стойку нет. Какой еще пример приведете — по второму разу коннекторы заставляют использовать?
Из личного опыта. В любой конторе от 30 юзеров нужно внедрять HelpDesk. Я не знаю как в других городах, но в Питере с этим плохо. HelpDesk должен выглядеть не как письмо в свободной форме, ловля админа в курилке, звонка по телефону, а как нормально оформленная заявка. Ставьте GLPI, OTRS, и другие подобные сервисы. Затем утверждайте бумагами что нет заявки — нет проблемы. В ситуациях когда человек не в состоянии написать заявку в силу ЧСВ, пусть за него пишет его секретарь и.т.д.
да не только 30, а и 10.
Как минимум это список выполненных администратором задач по хелпдеску.
А если одна из барышень в бухгалтерии настолько тупа что «подставку под кофе» ей за месяц ремонтировали 15 раз, это повод поменять барышню, у которой руки — крюки(с), и это сработает даже в конторе на 10 человек.
Если я прихожа и аргументированно говорю руководителю, что «юзер х — идиот, на которого я трачу полчаса в день, когда на остальных у меня уходит по 5-10 минут в день максимум, и вместо выполнения своих задач настраиваю юзеру х иконки на рабочем столе и т.п», то юзер х рискует как минимум быть вызванным на ковер с вопросом «а чем, простите, вы занимались 5 лет в ВУЗе, если не знаете свой профильный инструмент?»
Как минимум это список выполненных администратором задач по хелпдеску.
А если одна из барышень в бухгалтерии настолько тупа что «подставку под кофе» ей за месяц ремонтировали 15 раз, это повод поменять барышню, у которой руки — крюки(с), и это сработает даже в конторе на 10 человек.
Если я прихожа и аргументированно говорю руководителю, что «юзер х — идиот, на которого я трачу полчаса в день, когда на остальных у меня уходит по 5-10 минут в день максимум, и вместо выполнения своих задач настраиваю юзеру х иконки на рабочем столе и т.п», то юзер х рискует как минимум быть вызванным на ковер с вопросом «а чем, простите, вы занимались 5 лет в ВУЗе, если не знаете свой профильный инструмент?»
Про резервное копирование и план аварийного восстановления хорошо написано! Но, я бы все таки добавил еще и тренировки по восстановлению! Были случаи в моей практике, когда люди вызывали меня из-за того, — что бакапы-то вот они, а как восстановить — никто не знает! Рекомендую в таких случаях тренироваться на кошках — что бы было понятно — что куда и как восстанавливать!
ИМХО, этот список нужнее даже не сис.админам, а руководству компании — чтобы выдать своему админу и аккуратно попросить следовать. Советы, по хорошему, банальны, не требуют сильных вложений, и выгодны в первую очередь именно компании. (хотя бы потому, что это организуют работу и даёт хорошую оценку рисков).
Аналогично, имхо, те админы, которые сопротивляются этому, попросту не хотят быть или не видят себя IT-директорами, вне зависимости от реальной зоны ответственности.
Аналогично, имхо, те админы, которые сопротивляются этому, попросту не хотят быть или не видят себя IT-директорами, вне зависимости от реальной зоны ответственности.
вообще, это идея — IT-тренинги для руководителей.
Не всем дано и не все хотят быть IT директорами. Хотя это и не освобождает от необходимости следования упомянутым здесь рекомендациям и элементарному здравому смыслу. Я, например, плохо умею общаться с твердолобым не-IT руководством и доказывать что-то идиотам, посему перспектива стать руководителем меня не прельщает. Гораздо больше по душе мне решать чисто технические задачи развития и поддержки инфраструктуры. Поэтому я работаю в крупной организации, общаясь по насущным вопросам со своим IT руководством, которое прекрасно понимает все без объяснений «на пальцах».
Предыдущая работа меня научила абсолютно каждый шаг и решение дублировать по email'у. Ситуация, когда начальник с утра говорит одно, после обеда — абсолютно противоположное была обыденной и случалась каждый день. Поэтому приходилось после каждого разговора\митинга писать ему все тезисы и снизу приписывать: «Please confirm», при принятии решения — то же самое. Первое время было тяжко, потом уже на автомате. Три года прошло, уже почти отучился от этого, с текущим начальством подобных вопросов не возникает. Но все равно, по привычке, ключевые моменты отписываю, на что получаю недоуменный ответ: зачем это, мы же все обсудили.
Все ходы записаны? (с)
Читал буквально на днях тут-же на хабре «Больше бумаги — чище жопа!» согласовывайте все — суть поста.
В нашей профессии, господа, бумага с подписью ответственного — это очень важный агрумент! Начните с систематизации своей работы, продолжите в сторону систематизации парка техники, потом к систематизации сервисов, покажите начальству на сколько проще и прозрачней для него/вас стала/станет ваша работа. Хелпдеск — это хорошо, будет виден объем вашей работы с пользователями и осязаем результат произведенных вами улучшений.
Был случай на меня и напарника нагрузили внедрение бухгалтерской-1С по филиалам, а гл.буху обучение сотрудников. Факт установки и проведения начального обучения в каждой точке у каждого пользователя мы фиксировали бумагой под подпись. Через пол года после благополучного провала проекта «тонущий» гл.бух на ковре у директора пыталась весь «калл ситуации» свалить на нас, и если бы не та самая пачка подписанных АКТов мы скорей всего вылетели бы с работы вместо нее. такой вот опус, надеюсь выводы будут вам полезны.
В нашей профессии, господа, бумага с подписью ответственного — это очень важный агрумент! Начните с систематизации своей работы, продолжите в сторону систематизации парка техники, потом к систематизации сервисов, покажите начальству на сколько проще и прозрачней для него/вас стала/станет ваша работа. Хелпдеск — это хорошо, будет виден объем вашей работы с пользователями и осязаем результат произведенных вами улучшений.
Был случай на меня и напарника нагрузили внедрение бухгалтерской-1С по филиалам, а гл.буху обучение сотрудников. Факт установки и проведения начального обучения в каждой точке у каждого пользователя мы фиксировали бумагой под подпись. Через пол года после благополучного провала проекта «тонущий» гл.бух на ковре у директора пыталась весь «калл ситуации» свалить на нас, и если бы не та самая пачка подписанных АКТов мы скорей всего вылетели бы с работы вместо нее. такой вот опус, надеюсь выводы будут вам полезны.
А какова была причина фейла, если не секрет?
Пиратство? Сотрудники поставили пиратский софт от 1с?
Пиратство? Сотрудники поставили пиратский софт от 1с?
фи… как можно?! ;) Все проще, сотрудники бухгалтерий не осилили 1с самостоятельно, гл. бух им не помогла. Свое обучение мы им дали, как открыть, как закрыть и все что в нашем ведении и за то истребовали подпись «Базовый курс обучения прошел. Все понятно. ». На том их знания и закончились до момента проверки. Гл.бух же благим матом орала что ИТ-шники не научили пользоватся, а мы ей в рожу бумаги кипу с подписями сотрудников. Так предусмотрительность победила лень.
> сотрудники бухгалтерий не осилили 1с самостоятельно
сотрудники!
бухгалтерии!
1с!
Ох-ох, Пресвятые Джигурды! Так у них же там высшее бразование и прочие штуки, при приеме на работу знание такого ПО обязанность же.
Как так то?: О
> Так предусмотрительность победила лень.
Да уж, показательный пример. Спасибо вам за развернутый ответ.
сотрудники!
бухгалтерии!
1с!
Ох-ох, Пресвятые Джигурды! Так у них же там высшее бразование и прочие штуки, при приеме на работу знание такого ПО обязанность же.
Как так то?: О
> Так предусмотрительность победила лень.
Да уж, показательный пример. Спасибо вам за развернутый ответ.
ну не стоит столь категорично… год был всего лишь 2004 и электронный учет был вновинку, средний возраст той бухгалтерии был порядка 60 лет и вообще очень не многие бухгалтера, я вам скажу, имеют высшее образование. Мы с напарником им помогали чем могли, но… в итоге процентов 30 бухгалтеров просто уволились.
Если штатный системный администратор будет выполнять все эти шаги, то он таковым долго не останется и будет быстро расти вверх — до IT-директора
Если есть куда расти в фирме.
Плох тот эникей, который не мечтает стать IT-генералом.
ИМХО: плох тот эникей — который долго эникей. а хочет ли он быть CEO это совсем другая история.
Не могу не согласиться про то, что состояние перманентного эникея это не совсем хорошо. Однако не желание стать более профессиональным делает из «эникея» — «долгоэникея».
не путайте теплое с мягким :) Думаю, не каждый человек хочет стать выдающимся и известным, а некоторым это еще и не на пользу. Лично знаю несколько очень состоявшихся в профессиональном плане людей, которым для жизни вполне хватает своего уровня забот и о «генеральстве» он не помышляют. Яркий пример в истории — Диоклетиан выращивавший капусту.
Могу сказать про себя лично: я «инженер» до мозга костей и менеджером быть не хочу. Например, недавно отверг предложение быть руководителем бюджетного учреждения в котором тружусь (т.к. не мое это). На текущий момент продолжаю работать техническим специалистом, и себя восемь лет назад вспоминаю с улыбкой (например я думал (сейчас так не думаю), что у ADSL модема нет и не может быть ip-адреса, это же не сетавая карта ;).
Видимо вы поняли меня буквально. По сути «состоявшийся в профессиональном плане человек» и есть «IT-генерал», я это имел ввиду.
Видимо вы поняли меня буквально. По сути «состоявшийся в профессиональном плане человек» и есть «IT-генерал», я это имел ввиду.
Я полностью с вами согласен, жаль, плюсануть не могу. Из эникеев можно расти очень много куда. Я стал инфраструктурным админом, многие коллеги по прежним местам работы — кто в сетевики подался, кто в 1С, кто в интеграцию, а кто-то вообще в SAP/кодинг. Одна моя знакомая вывела следующую формулу: «Эникейщиков не бывает. Бывают вечные эникейщики и бывают админы, которые на данный момент имеют мало опыта».
В этом и соль — выполняете все шаги, составляете инструкции, берете вместо себя менее опытного сотрудника с описанием — что делать и как следить за парком, а сами переходите в компанию покрупнее со строчкой в резюме «организовал бесперебойность работы IT-инфраструктуры» и рекомендацией от руководителя. Ну это, понятно, в идеальном варианте :)
Вкусно, но мало.
Небольшое дополнение в ваш чек-лист: заведите небольшой парк подменных компов/ноутбуков для сотрудников. Пусть они будут не очень новыми и в небольшом количестве, однако это резко снизит проблемы от необходимости кому-то срочно восстановить рабочее место. Ну и само собой все данные сотрудников должны храниться в сети. Почта, документы, всё.
PS: Хотя это и must have, на практике такое встречается только в больших серьезных компаниях.
PS: Хотя это и must have, на практике такое встречается только в больших серьезных компаниях.
Сейчас при существовании VirtualBox можно сделать «временные рабочие места» чтобы посадить человека за машину с виртуалкой, развернуть ее быстрее. Получится так что и админ может заняться делом восстанавливать основное рабочее место и проблемный сотрудник не останется без дела, т.к. рабочее место, пусть и временное у него есть!
Все равно физическая машина нужна, верно?
Как правило мы стремимся сделать бэкап, ведь востановление из бэкапа занимает как правило не больше 40 мин. ну и настройки ярлыков минут 5 + работа rsync по синхронизации важных рабочих файлов.
Все это здорово и занимает не больше 1.5-2 часов. А что нет бэкапа или не восстанавливается, или вдруг полетела материнка, а другой такой же нету? Ситуация когда нужно сделать все с нуля не такая уж редкая.
Поэтому поставить VmWare(к примеру заранее на заранее выделенную машину для этого) и развернуть образ виртуалки это значительно быстрый ввод сотрудника испытывающего проблемы чем ожидание этим сотрудником, когда же админ настроит его основное место.
Все это здорово и занимает не больше 1.5-2 часов. А что нет бэкапа или не восстанавливается, или вдруг полетела материнка, а другой такой же нету? Ситуация когда нужно сделать все с нуля не такая уж редкая.
Поэтому поставить VmWare(к примеру заранее на заранее выделенную машину для этого) и развернуть образ виртуалки это значительно быстрый ввод сотрудника испытывающего проблемы чем ожидание этим сотрудником, когда же админ настроит его основное место.
Да я не спорю, виртуалки значительно упрощают эти проблемы. Речь о том, что нужна подменная машина, которую можно дать сотруднику, пока ремонтируется его основная. Исправная и готовая заработать в течение минут. Часто бывает что у админов их просто нет. Или есть по частям, разобранные.
Ну не все так плачевно. Достаточно часто вижу, что какой-нибудь старенький компьютер идет в утиль или еще куда, просто нужно забрать себе на нужды ;) Или в лоб спросить руководство о покупке резервного компа. Сейчас за 10 можно с рук взять достаточно хороший, а это не такие уж и большие деньги, а если руководство говорит «очень большие деньги», то возникает вопрос: А в правильном ли месте Вы работаете?
Я делал статью про управленческие компетенции для системного администратора, а не о том, как ему следует делать свою непосредственную работу.
Ушёл проверять бекапы.
Задавая этот вопрос, я себя чувствую безусым нубом, но все-таки спрошу. А как правильно проверять бэкапы в виде mysql дампов? У меня на серверах бэкапы мускуля делаются через mysqldump, потом через rsync over ssh или sshfs сливаются на бэкап-сервер и там архивируются и, по необходимости, шифруются.
Проверяются они изредка ручками, просто пытаюсь их развернуть в виртуальной копии боевого сервера. Но с дампами > гигабайта это мягко говоря напряжно. Я интуитивно чувствую, что где-то что-то делаю не так. Возможно более продвинутые коллеги меня направят верной дорогой? Спасибо.
Проверяются они изредка ручками, просто пытаюсь их развернуть в виртуальной копии боевого сервера. Но с дампами > гигабайта это мягко говоря напряжно. Я интуитивно чувствую, что где-то что-то делаю не так. Возможно более продвинутые коллеги меня направят верной дорогой? Спасибо.
Директор — тоже человек. Подпишет «раз в год делать бекап», на словах скажет «давай-ка почаще», а взгреет, что бекап отставал от реальности на час — и будет (как ему кажется) прав.
Вывод один — искать адекватных работодателей. А работодателям — искать адекватных админов :))
Не могу не вспомнить знаменитое «о, классный скрин-сейвер, так хорошо огонь нарисован!» — в ИТ остается только с юмором относиться к реальности )))
Вывод один — искать адекватных работодателей. А работодателям — искать адекватных админов :))
Не могу не вспомнить знаменитое «о, классный скрин-сейвер, так хорошо огонь нарисован!» — в ИТ остается только с юмором относиться к реальности )))
Как замечательно: теоретики дают советы практикам.
Почему мне курсы, на пример от Cisco, по душе:
вот есть CCNA Security в котором кроме настройки VPN-ов и L2/L3 угроз и методов защиты, описывают разные моменты в работе с ИТ технологиями.
Оказывается, хорошо:
— иметь хотя бы минимальный документ описывающий Политику безопасности (англ. organizational security policies), о котором все знают и подписывали,
— не избегать рисков, а уметь аргументировать и сводить к минимум разные типы угроз,
— проводить регулярные, хоть и минимальные, воспитательные работы в рабочее время (просто объяснить что так нельзя, а так лучше)
и т.д.
Можно взглянуть как бы со стороны на уже знакомые вещи но более глобально, узнать вещи о которых может и не догадывался.
вот есть CCNA Security в котором кроме настройки VPN-ов и L2/L3 угроз и методов защиты, описывают разные моменты в работе с ИТ технологиями.
Оказывается, хорошо:
— иметь хотя бы минимальный документ описывающий Политику безопасности (англ. organizational security policies), о котором все знают и подписывали,
— не избегать рисков, а уметь аргументировать и сводить к минимум разные типы угроз,
— проводить регулярные, хоть и минимальные, воспитательные работы в рабочее время (просто объяснить что так нельзя, а так лучше)
и т.д.
Можно взглянуть как бы со стороны на уже знакомые вещи но более глобально, узнать вещи о которых может и не догадывался.
Я бы еще добавил пункт «старайтесь максимально стандартизировать и автоматизировать все действия — разумеется, не в ущерб продуктивности». Вот вам пример.
Когда-то я работал эникеем в автомобильном дилерском центре. Там было очень много специфических ноутбуков (как правило, Panasonic Toughbook CF-серии) с кучей хитрого марочного софта, использовавшихся для диагностики или прошивки автомобилей. Критичными были не хранящиеся на них данные сами по себе, а именно этот самый марочный софт, который настраивался очень долго, очень муторно и с непредсказуемыми последствиями, отказ же софта означал задержки в ремонте автомобилей.
Я внедрил систему сетевого восстановления через PXE, при которой пользователю при отказе диагностического ноута было достаточно просто загрузить его по сети и нажать одну кнопку, после чего туда автоматически разворачивался бэкап образа ОС именно этого ноута. Зачастую это оказывалось быстрее, чем поиск проблемы и ее решение силами IT, ибо поддержка производителя для такого софта либо отсутствовала вовсе, либо была очень медленной. Бэкапы, разумеется, периодически обновлялись. А поскольку актуальность данных особой роли не играла, а важна была только корректно настроенная и работающая свежая версия марочного софта, то бэкапы делались как раз при обновлении этого самого софта.
После внедрения этой системы я забыл про «задерживаться на работе, потому что надо срочно!!!111 починить ушатанный диагностический ноут».
Когда-то я работал эникеем в автомобильном дилерском центре. Там было очень много специфических ноутбуков (как правило, Panasonic Toughbook CF-серии) с кучей хитрого марочного софта, использовавшихся для диагностики или прошивки автомобилей. Критичными были не хранящиеся на них данные сами по себе, а именно этот самый марочный софт, который настраивался очень долго, очень муторно и с непредсказуемыми последствиями, отказ же софта означал задержки в ремонте автомобилей.
Я внедрил систему сетевого восстановления через PXE, при которой пользователю при отказе диагностического ноута было достаточно просто загрузить его по сети и нажать одну кнопку, после чего туда автоматически разворачивался бэкап образа ОС именно этого ноута. Зачастую это оказывалось быстрее, чем поиск проблемы и ее решение силами IT, ибо поддержка производителя для такого софта либо отсутствовала вовсе, либо была очень медленной. Бэкапы, разумеется, периодически обновлялись. А поскольку актуальность данных особой роли не играла, а важна была только корректно настроенная и работающая свежая версия марочного софта, то бэкапы делались как раз при обновлении этого самого софта.
После внедрения этой системы я забыл про «задерживаться на работе, потому что надо срочно!!!111 починить ушатанный диагностический ноут».
на самом деле, полезный текст. itsm, регламенты и вот это всё.
но не хватает основного пункта, пункта 0
для меня он звучит так:
0. даже если вы работаете «на дядю», делайте работу не как «работодатель — работник», а как b2b. т.е. клиент — сервис.
и это будет залогом успеха.
но не хватает основного пункта, пункта 0
для меня он звучит так:
0. даже если вы работаете «на дядю», делайте работу не как «работодатель — работник», а как b2b. т.е. клиент — сервис.
и это будет залогом успеха.
Я бы назвал это выжимкой из книги:
Системное и сетевое администрирование. Практическое руководство
Рекомендую книгу к прочтению и перечитвыванию.
Полезно для себя выписывать тезисы ;)
Системное и сетевое администрирование. Практическое руководство
Рекомендую книгу к прочтению и перечитвыванию.
Полезно для себя выписывать тезисы ;)
Продолжение статьи: habrahabr.ru/post/193186/
Sign up to leave a comment.
Инструкция по выживанию для штатного системного администратора