Глупые мысли об IT

Привет, народ!

Не уверен, писал ли я на эту тему или нет, но мне кажется она важной: как документировать проблемы при работе над проектом. Формально - это одна из обязанностей менеджера проектов (МП), технический специалист (ТС) не должен вести подобного типа документацию. Но иногда бывает, что МП по каким-либо причинам этого не делает, поэтому я самостоятельно начинаю документировать различные проблемы для своей же безопасности.
Не секрет, что часто большие проекты не всегда идут гладко: то возникают какие-то проблемы (в худшем случае – проект приходится закрывать), то происходить выход за границы бюджета, либо отставание по срокам. Вот тут-то начальство и другие люди, участвующие в проекте, начнут искать, на кого “повесить всех собак”. Как раз для эти случаев у меня наготове обычно два документа: “Incident log” (“журнал проблем”) и “Lessons learnt” (“выученные уроки”). Сразу же подчеркну: содержание этих документов должно “тонко подстраиваться” под каждую конкретную ситуацию! Т.е. то, что с вас потом будут спрашивать. Вы сможете потом подтвердить документально все факты и так же их “количественные” и “качественные” характеристики.
По моему опыту, в случае проблем/инцидентов всех интересуют следующие вещи:

1. Когда это произошло. Если проблема не решается быстро, надо знать, как долго она тянется. Либо, если решение проблемы не зависит от вас, как долго вы ждёте действий от кого-то другого;
2. Относится это напрямую к области вашей ответственности или нет. Вполне возможно, что кто-то “спихнул” проблему на вас и вы кучу времени потратили на “разруливание ситуации”, на которую вы не должны были тратить время. Но это же забирает время и ресурсы!? Такая классификация позволяет в дальнейшем доказать, что задержки были вызваны не непосредственно вашими действиями, а внешними факторами. Из последнего моего проекта 11 из 23 проблем не относились к тем изменениям, которые я и моя команда сделали. Порядка 55 часов было потрачено, чтобы решить проблему и доказать, что она возникла не из-за нас. Это огромная цифра;
3. Краткое описание ситуации и проблемы – тут важно правильно всё написать, чтобы потом избежать “переопределения” ситуации и разговоров о том, что было “это”, а не “это”;
4. Влияние на проект (“критическое”, “среднее”, “малое”, “незначительное” и т.п) – для установки приоритетов для решения проблем;
5. Влияние на бизнес (“критическое”, “среднее” и т.п.) – иногда вышестоящие менеджеры не в курсе, насколько значительно происшествие. Категоризация позволит избежать “получения по шапке” за малозначимое событие;
6. Статус инцидента – “закрыт” или всё ещё “открыт”;
7. Причина/что вызвало происшествие – краткое описание как можно в более простых терминах причины события. Более детальная и “техническая” информация заносится (так, по крайней мере, я делаю) в другой документ – “Lessons learnt” (“Выученные уроки”). Об этом чуть позже;
8. Сколько времени потребовалось на диагностику причин проблемы, причём это не включает в себя время, потраченное на устранение. Во время последнего проекта это время колебалось между 1 часом и 1 днем. Суммарно потратили 152 часа (на все инциденты), среднее время для нахождения причины – 7 часов. Это время надо учитывать особенно в том случае, если проблема была вызвана не вами. А вот решение проблемы может практически и не занять много времени;
9. Время, потраченное на устранение инцидента и его последствий – максимально точное время потраченных усилий. Опять же, из последнего проекта – 39 часов суммарно, 2.5 часа в среднем на проблему. Разница существенная между диагностиком и устранением. “Дельта” показывает начальству, куда ушло время. Особенно, если оно было зря потрачено на “бодание” между различными командами. В нашем случае так часто и было;
10. Действия, предпринятые для устранения проблемы в короткий срок – что было сделано, чтобы вернуть какой-либо сервис в нормальную работу. Вполне возможен “костыль”, если надо что-то сделать очень быстро. Но это должно быть описано и задокументировано. Инцидент может быть не закрыт, если бизнес не удовлетворён решением проблемы;
11. Действия для недопущения проблемы в будущем. В отличие от предыдущего пункта, после этого инцидент можно формально будет считать закрытым.

Как я уже сказал, содержимое этого документа определялось вопросами от вышестоящего начальства по поводу проблем в процессе внедрения проекта. Вполне возможно, что что-то можно добавить, а что-то можно удалить. “Документ” – понятие вполне “живое” содержимое может меняться со временем.
По п.11: в него можно добавлять ссылки на документ “Lessons learnt”, но об этом чуть позже.

Засим раскланиваюсь,
Рустам.

Привет, народ!

Недельки две назад “добил” последний экзамен на гордое звание MCSE: Windows Server 2012. Я решил сдать этот экзамен за день отъезда в командировку, поэтому пришлось срочно искать центр тестирования у которого была свободна эта дата. Немного пострадал из-за доверия к MS: когда я выбирал экзамен, мне было сказано, что этот экзамен доступен для сдачи издому! Т.е. запускаешь у себя на компьютере программу, которая мониторит тебя через вебкамеру и микрофон и сдаешь себе экзамен в тепле и уюте домашней обстановки. Поэтому я и не торопился с датой. Но когда уже начал записываться на экзамен, то получил дулю в виде сообщения, что в моей стране опция домашней сдачи недоступна. Из-за этого и была вся чехарда и спешка. Для меня в пределах доступности был только один центр тестирования в Рединге. Меня удивило, что в нём была куча свободных слотов. Но когда добрался к этому центру, я понял, что это не учебный центр, а так, пара классов для сдач экзаменов. Там даже £1 пытались брать за посещение туалета, но я их обманул :)
Сам экзамен, как мне кажется, будет немного легче 70-413. Может быть, из-за того что сетевым вопросам (RRAS, NPS и т.д.) почти не уделялось внимания. Основной упор: кластеры, виртуализация, т.е. высокая доступность серверов и восстановление после сбоев. Формат такой же, как и в 70-413: дается сценарий, потом шесть вопросов. Затем совершенно другой сценарий и вопросы. После может идти пачка вопросов с выбором ответа из списка. Основная сложность экзамена – в количестве информации в сценариях и неоднозначности. Мне кажется, что в некоторых вопросах возможно было выбрать два правильных ответа. Например, было сказано, что у компании есть два главных серверных центра и два резервных. В главных развёрнуты Hyper-V кластера. Надо развернуть серверы для приложения. Где это сделать? Я долго мучился с выбором, просто не видел разницы между главными центрами. Судя по баллам, которые я набрал, отвечал я правильно. Может, мне повезло и я угадал в некоторых местах. Но набрал я 833 балла из 1000 при проходном 700. Сам удивился :)
А теперь я готовлюсь сдать два экзамена на MCSE Desktop. Честно – сам не понимаю, когда это закончится. Я уже даже не надеюсь обновить VCP и CCEA, мне бы успеть обновить сертификацию MS до того, как снова выйдут новые версии :)

Засим раскланиваюсь,
Рустам.

Привет, народ!

Пройдена ещё одна веха по пути сертификации на почётное звание специалиста по серверной инфраструктуре :) Неделю назад сдал “70-413 - Designing and Implementing a Server Infrastructure”. Подготовка прошла гораздо быстрее, чем к 70-412, так как “матчасть” я уже выучил и надо было только пройтись по материалам учебного курса.
А вот сам экзамен был гораздо сложнее, чем я ожидал. И не столько из-за сложности вопросов, сколько из-за формата.
Основной принцип экзамена – предоставить сценарий с кучей информации, затем идёт порядка 5-6 вопросов. Сначала очень детально пытался разобраться с большим объёмом информации, затем отвечал на вопросы. После этого перешёл… совершенно другой сценарий и вопросы! Т.е. время, которое потратил на изучение информации в первом случае практически ушло впустую. Там было очень много данных, которые никаким образом не относились к задаваемым вопросам. После третьего сценария я уже просто изучал текст на экране, мысленно выделяя какие-нибудь странные моменты, затем переходил к вопросам и выискивал в тексте нужную информацию.
После сценариев настала очередь вопросов в формате: какая-то информация, затем утверждение и надо было ответить на вопросы: “информация правдива, но утверждение ложно”, “информация ложна, утверждение ложно” и т.п. Например (выдумал сам): “Чтобы добиться устойчивости DHCP сервиса, надо установить дополнительные DHCP сервера. Утверждение: установите DHCP сервер в кластер”. И т.д. Всего было около 30 подобных вопросов.
Когда я ответил на вопросы, я уже был готов увидеть результат, но я рано радовался. С точки зрения MS та пачка вопросов была приятным перерывом в экзамене и потом снова пошли сценарии!!! У меня уже мозги плавились и я уже почти отчаялся. К моему облегчению после пары проходов по сценариям я увидел отчёт об экзамене: сдал! Набрал 700 баллов при проходном – 700 :)
Честно говоря, были сомнения о результате. Очень много вопросов было про удалённый доступ, организацию безопасного доступа на основе RRAS/RADIUS/VPN/NPS и т.п., а я в этом в деле “плаваю”. Я в этом разделе ответил хуже всего, набрав где-то 50% правильных ответов. Этот раздел даёт около 20%-25% в итоговую оценку. Т.е. если правильно отвечать на остальные вопросы, то можно “прорваться” :)

Засим раскланиваюсь,
Рустам.