• Как правильно вести техническую документацию Системному администратору?

    @leobatura
    network engineer
    С опытом пришло понимание, что должно быть вот так:

    1) Идёшь в бухгалтерию, берешь там список имущества, которое числится на тебе / на отделе, проходишь по всем -- сверяешь, вплоть до старой гарнитуры, всё должно сойтись. Лицензии на ПО точно также. Ты должен в любой момент времени точно сказать -- где, что и сколько у тебя стоит, сколько на складе, что ты заказал, что пришло и то ли пришло. Для бухгалтерии это всё коробочки с лампочками. ОБЯЗАТЕЛЬНО! должны биться серийные номера. Если их нет требуй присвоить инвентарный. Даже на картридже для принтера. Если условная Света из логистики принесла свою мышь, у тебя должно быть это отображено. Всё с парком машин происходить только с твоего ведома.
    Не бойся обращаться к руководству -- оно оценит, что ты экономишь их деньги.
    Всё, что ты выдаешь -- выдавай под роспись. Это дисциплинирует.

    2) Схема сети. Видеонаблюдение и телефония. Как нарисованная, так и WeatherMap в Cacti. Многие ей пренебрегают, почем зря. Ты всегда должен знать что у тебя происходит с каналами связи. Все вланы, все адреса, местоположение должно быть отражено и подписано. Все стойки и шкафы должны быть сфотографированы, так чтобы было чёткое понимание, что-куда-зачем.
    Поверь, в случае аварии тебе это очень сократит время на восстановление.
    aid1284150-v4-900px-Create-a-Network-Doc

    3) Маркировка оборудования. Всё, нет не так -- ВСЁ!!! должно быть подписано. Все розетки, все патчи. Вообще всё!

    4) Делаешь себе локальную вики, пох на чем и пишешь туда АБСОЛЮТНО всё. Как настроить порт на коммутаторе, набор основных команд, диагностика, версия прошивки, какая-то основная конфигурация. Бэкапы конфигурации храни в текстовом виде, не доверяй всяким .cfg, как настроить vlan на микроте, как поднять VPN до соседнего офиса.
    Тебе это очень сильно сократит время, особенно некоторые операции надо проводить довольно редко.

    5) Пиши скрипты для рутины. Скрипты тоже должны быть в вики.
    Допустим обновить 5 коммутаторов или поправить ACL ненапряжно. А если их 50? 150?

    6) В вики не должно быть ни одной ссылки на сторонние ресурсы. Завтра страница переедет, а ты на нее надеялся.

    7) У тебя должны быть контакты всех поставщиков услуг, что касается твоего отдела: провайдеров, заправщиков, инженеров, горсетей, номера договоров, и прочая херня Если что-то случилось, ты должен очень быстро получить ответы, а не ждать на горячей линии. Держи контакты актуальными.

    8) Чтобы это всё имело хоть какой-то смысл -- трать 1 час в день, чтобы заняться документацией. Иначе всё это херня.
    Ответ написан
    2 комментария
  • Какой материал выбрать для изучения основ управления проектами?

    nki
    @nki
    bezkart.ru готовая система лояльности
    Рекомендую начать с этой книги. Простым и доступным языком описаны необходимые основы.
    Ответ написан
    Комментировать
  • С чего начать изучение моделирования, анализа и оптимизации, автоматизации безнес-процессов новичку?

    denisgorbunovmsc
    @denisgorbunovmsc
    руковожу проектным офисом
    "еще очень интересует решение проблем оптимизации и автоматизации бизнес-процессов с помощью it-технологий."
    Это очень общее.
    1) Слово ИТ тут очень второстепенное, для начала нужно учиться ловить поток операций и видеть узкие места. Тут лучше Голдратта я ничего не знаю. За теорией к нему. Самое простое на рутрекере найти видосы с его семинаров. Не найдешь, обращайся.
    2) Чтобы разбираться в процессах нужна тренировка и заточенность мозгов под это дело. Сидишь пивас в кафе пьешь, смотришь официантки нервничают. А чего так? А потому что пятница народа много у них. Не хватает персонала? Или мешаются друг другу? Или нервничать начали, а менеджер хрен пинает? А что с этим можно сделать? А тут наоборот не мешаются, а почему? А что этот человек делает? А этот? И так далее.
    Умение видеть процессы - то чему не учит ни средняя школа, ни высшая. Там нас учат, что нас окружают не процессы, а явления и факты. На самом деле вокруг нас только переходные процессы. За подробностями - в философию. Но суть в том, что для описанных вами задач нужно уметь видеть везде не только процессы, но и узкие места в них.
    3) Полезно подучить методологию описания бизнес-процессов. Их несколько. Мне нравится вообще примитивные подходы типа "User story mapping" by Jeff Patton. Тут главное сильно не задрачиваться в сложные схемы, так как их все равно Заказчик не понимает.
    4) Вот теперь уже можно почитать и про инжиниринг процессов и все что с этим связано в преломлении ИТ.
    5) Никто не отменял практический опыт, за который платят деньгу. Чем сильно в теорию углубляться, если нет опыта, проще пойти аналитиком стажером - там научат (правда по вечерам и в режиме аврала).
    Ответ написан
    Комментировать