Многим сисадминам, которые работают с SCCM, хотелось бы иметь возможность управлять не только Windows компьютерами, но заодно и Mаками. С данной задачей поможет справиться наш продукт — Parallels Mac Management (PMM). Фактически, это расширение для системы SCCM, позволяющее управлять Maками из знакомой консоли System Center, пользуясь уже сложившимися практиками. На стороне Mac работает наш клиент под root’ом, что позволяет администрировать систему в полном объеме. Под катом рассказ нашего тим-лида Тимофея Фуряева об основных трудностях, с которыми мы столкнулись при разработке PMM.

Для кого этот текст

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



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

Ну и для сис-админа SCCM, который не знает про наш замечательный продукт. Тут будет немножко откровенной рекламы нашего продукта — мы очень любим его делать, и любим, когда его покупают :) А чтобы вы не могли её (рекламу) просто так промотать, я рассовал её по тексту, как ложечки дегтя в бочке с медом.

Почему мы этим занялись

Почему мы полезли в этот самый корпоративный сегмент? Ни для кого не секрет, что Parallels давно и успешно занимается виртуализацией Windows на Маках. Накопленная экспертиза требовала выхода в попытке подружить эти два мира в плане системного администрирования.

Во многих компаниях давно стоит задача администрирования парка компьютеров, и она успешно решена многими программными решениями, в частности, при помощи System Center Configuration Manager от компании Microsoft. SCCM позволяет управлять компьютерами под управлением Windows, и даже Linux. А вот с OS X (ныне —macOS) как то не сложилось. На рынке есть несколько специализированных решений для централизованного управления Маками. Но не всем хочется устраивать зоопарк из подобных решений.

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

О чём надо подумать заранее

Все, что может пойти не так, пойдет не так! Это — непреложный закон Мерфи. Избежать этого, видимо, нельзя. Но желательно иметь хотя-бы список “нетаков”, чтобы к этому подготовиться. И постараться подумать заранее о разном.



(сцена из фильма Эволюция: “режьте ногу!”)

О насущном

Концепция Minimum Viable Product (MVP) имеет как своих поклонников, так и противников. Если ваш продукт можно весь написать за полгода, то MVP для вас — пустой звук. Но в нашем случае для полноценного продукта требуется потратить многие годы работы большой команды. Не стоит тратить эти годы только для того, чтобы узнать, что вы ошиблись с выбором функциональности в самом начале, и клиентам надо совсем не то, что получилось.

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

Network Discovery — сканирование локальной сети при помощи Nmap для обнаружения неуправляемых (пока что) Маков в локальной сети, и введения их в SCCM.

Inventory Reporting — отсылка отчетов для инвентаризации, которые содержат много полезного: информацию о железе, установленному софту, и т.д.

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

Мы планировали выпустить первую рабочую версию через 9 месяцев после старта разработки. Однако «роды» задержались на целых 1.5 года. Потом еще один год мы потратили на то, о чем просили живые пользователи, а не на то, что нам самим изначально казалось важным и нужным. Так появились установка пакетов приложений и профилей конфигурации. Если бы вместо 2 фич мы стали делать 20, то первые пользователи появились бы у нас гораздо позже.

О перспективах

Лично для меня это стало новостью — корпоративные клиенты покупают перспективу. Даже если у вас есть далеко не всё, что им нужно, но есть хороший план на несколько лет вперед, ваш продукт уже могут покупать. Звучит ободряюще, но есть и обратная сторона — план нужно иметь, поддерживать в актуальном состоянии и, самое главное, выполнять.

А план — это не просто набор фич, это ещё и очередность их выхода. Казалось бы, что может быть проще? Берете список фич, и просите ваших клиентов (или потенциальных клиентов) проставить номер приоритета. Оказалось, что это задача непосильна для многих клиентов. Они просто ставят всему нужному максимальный приоритет.

И тут вам придется проявить изобретательность. А вот что нас совсем разочаровало, так это бета-тестирование. Тут всё плохо, совсем. Мы сделали несколько подходов к проведению бета-тестирования среди наших клиентов, и все они с треском провались. Хотя сами клиенты с готовностью заявляли о желании потестировать, но нарисовалось три «НЕ»:

1. НЕгде — подготовка и развертывание лабораторных стендов занимает много времени. Стенд может состоять из пяти-десяти разных виртуальных машин. Может потребовать хитрого механизма развертывания. Может бояться откатывания к чистым снэпшотам.

2. НЕкогда — чтобы что-то протестировать, нужно изучить новую функциональность. Она, по определению, может не работать так, как надо. Придется обращаться к нам за помощью. Мы то с радостью, но…

3. НЕкому — текущую работу у сис-админа никто не отбирал. Ну, вы поняли.

О безопасности

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

Где-то рядом с безопасностью стоит вопрос конфиденциальности данных, которые вы можете получать от клиентов. У нас в продукте есть подсистема Customer Experience Program. Если коротко, она отсылает обезличенную статистику по использованию различных фич, чтобы мы знали, что реально используется клиентами, а что нет.

Тут рекомендаций совсем немного:

• Делать это надо с разрешения пользователей
• Не надо собирать конфиденциальную информацию (явки, пароли, и т.д.)

С этой системой связан один эпизод, который меня удивил, и окончательно утвердил для меня её пользу. В некоторый момент нам очень захотелось не заморачиваться с поддержкой старых версий OS X (10.9 и 10.10) при создании новой фичи. Если посмотреть на статистику, то таких Маков должно быть около 20%. Вроде бы, для начала можно было бы сконцентрироваться на оставшихся 80%. Но данные наших CEP отчетов меня обескуражили — 48% — вот доля таких маков у наших клиентов. Освежает, не так ли?!

О ручной работе

Вначале бог сделал тестирование ручным. И всё было довольно гладко — фич было мало, платформ мало, красота! Стоит заметить, что сперва мы поддерживали только SCCM 2007 и только Primary Sites, и Windows Server 2003. Затем вышел SCCM 2012, Windows Server 2012, новый SQL Server. Фич стало больше, еще больше, совсем много. Мы стали поддерживать разные варианты иерархии SCCM, такие как CAS и Secondary Sites.

Возникли трудности с развертыванием тестовых стендов. Стенды эти состояли сначала из двух виртуальных машин, и через непродолжительное время стали насчитывать до 5-7 машин. И количество самих стендов быстро перевалило за пару десятков. Нам было бы совсем туго, если бы мы не сделали систему автоматического развертывания тестовых стендов из шаблонов виртуальных машин. Позднее эта система стала частью системы автоматического тестирования, а вначале сильно помогла в ручном.

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

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

О железе

Сейчас каждый админ знает про Mobile Device Management (MDM). Но, наверное, не все знают про такую замечательную надстройку над ним, как Apple Device Enrollment Program. Суть её в том, что при покупке нового Мака вы можете составить список требований к его настройке таким образом, что уже при его первом включении — еще до входа пользователя в систему — он будет привязан в вашей системе и настроен нужным образом. И все это произойдет автоматически.

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

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

О вечном

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

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

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

• Стенды для освоения продукта, сложность которых уже была упомянута
• Обучение работе с продуктом. Сложность тут в том, что знать надо не только Parallels Mac Management, но и сам SCCM. А также нужны некоторые знания об администрировании Windows Server, Active Directory, и так далее
• Знакомство с новыми фичами. Продукт активно развивается, приходится активно развиваться и инженерам поддержки

Есть еще такие люди, как sales engineers. Они реально продают, и реально разбираются в продукте. И если продавать они умеют (кажется) с рождения, то для «разбирания-в-продукте» надо приложить усилия, как и в случае с тех-поддержкой.

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

Ну и самим нам иногда приходится просить о помощи у коллег. Есть у нас такая фича — управление шифрованием FileVault2 на Маках. При её тестировании на виртуальных машинах у нас внезапно возникла проблема: после включения шифрования требуется перезагрузка Мака, чтобы шифрование собственно началось. Так вот после перезагрузки виртуалка «ломалась», на тот момент в Parallels Desktop не было поддержки шифрования FileVault2 в гостевой системе. Пришлось просить коллег из команды Parallels Desktop её реализовать. Здорово иметь влиятельных друзей!

Итог

Вообще-то рано говорить об итогах. Нашему продукту исполнилось 6 лет, что совсем немного для корпоративного софта. За это время мы реализовали множество полезных вещей:

? Поиск Маков в AD
? Запуск скриптов на Маках
? Портал самообслуживания для установки приложений
? NetBoot с поддежкой Task Sequence для установки OS X по сети, с множеством типов шагов.
? Установку обновлений OS X
? И многое другое.

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