Доброго времени суток, уважаемые Хабровчане.

     В качестве краткой предыстории: год назад, придя на новое место работы в качестве руководителя отдела разработки БД (на базе Microsoft SQL Server), я испытал глубочайший шок от увиденного. Крупная компания, сложное веб-приложение, многомиллионные контракты, а разработка ведется на production-БД, баг-репорты поступают и обрабатываются по методике «кто громче крикнет» или «надо сделать прям вчера». Естественно ни о системе контроля версий, continuous integration, процедурах и workflow речи и не шло.

     Сегодня ситуация сильно изменилась (хотя, кого я обманываю — только начинает меняться) и я хотел бы поделиться как техническими, так и процедурными деталями решений, которые мы используем сейчас. Технические детали на 90% касаются непосредственно разработки для Microsoft SQL Server, а вот процедурные изменения у нас коснулись и веб-девелоперов, и инженеров, и аналитиков, и тестеров.

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

     Кому интересны подробности — добро пожаловать под кат.
Warning: очень много текста, описания процедур и процессов (которые, может, никому и не интересны).

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

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

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

Доброго времени суток, уважаемые хабровчане.

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

Благодаря этому опыту, а также счастью работать в полностью ITIL-compliant организации, у меня сложился ряд представлений о том, как должна вестись работа (речь скорее о внутренней «кухне»). Хотелось бы ими с Вами поделится. На их правильности я не настаиваю, однако такое «кредо» очень здорово помогает мне (а, соответственно, и моему работодателю) вести успешную работу и не переставать радовать клиентов.

Все остальное — под катом.

Добрый день!
Недавно передо мной встала задача — быстро установить большое количество Zabbix-агентов на Windows-сервера.
Я решил, что это можно и нужно решать с помощью скриптов. В качестве «языка» я выбрал любимый мной (и не только мной!) Powershell.
Небольшой мануал Вы найдете под катом!

Недавно мне пришлось обновлять WSS 3.0 на Sharepoint Foundation 2010. Хочу поделится опытом, а также рассказать о проблемах, которые Microsoft «прячет» от нас.
Предисловие:
Windows Sharepoint Services был установлен как Stand-alone сервер, использует Windows Internal Database Engine. Хочу обновить ферму до Sharepoint 2010 Foundation. Остальное — под катом. Кому интересна финальная рабочая процедура – в нижнюю часть статьи.

Я хочу описать сложности, с которыми администратор может столкнуться при настройке Exchange для нескольких доменов. Я не буду вдаваться в подробности решения данных проблем, однако опишу в общих словах как их следует решать и предоставлю ссылки на ресурсы (Microsoft или блоги специалистов по Exchange) где описано подробно решение тех или иных сложностей.
Я стараюсь обхватить как можно больше «тонкостей», однако что-то мог и забыть :)

Кому интересно – под кат. Внимание: очень много букв!

Доброго времени суток!
Данная статья описывает мой опыт построения отказоустойчивого почтового сервиса Microsoft Exchange 2010 SP1.
Она полезна по большей части новичкам для того, чтобы разобраться в теории.
Я не буду углубляться в практические аспекты, а постараюсь изложить теоретическую базу, необходимую при построении отказоустойчивого кластера Exchange.
Все остальное – под катом. (Много текста!)