Тред про ОС как продукт
1/ Окей, поехали :) Операционная система (ОС) — это то, что бегает на девайсах. За редкими исключениями это что-то Linux/Android-based, но сильно кастомизированное под собственные нужды
2/ Получается, мы просто взяли готовый linux дистрибутив, поменяли название, обозвали его своей операционной системой и радуемся? Зачем об этом рассказывать, и вообще продуктовая ли это задача?
3/ Смотрите, тут неоднозначно. В основе почти всего на рынке действительно есть какой-то дистрибутив, который написан кучей крутых людей и уже менеджит бОльшую часть вещей. Но дальше начинаются нюансы ;)
4/ Хочу рассмотреть реальный пример для WiFi, потому что эта функциональность вроде как коммодити, и в 2021 году почти любой ноутбук и дистрибутив умеет законнектиться к вайфаю
5/ Открытые вопросы для WiFi:
- предположим, девайс умеет в WiFi; какие конкретно протоколы безопасности он должен поддерживать (WPA2, WPA-EAP)? Какие сегменты юзеров мы потеряем, если не будет поддержки enterprise security?
- должен ли юзер иметь возможность задать статические настройки сети, или будем поддерживать только условный DHCP?
- девайс не может приконнектиться к WiFi; что увидит юзер на экране? Есть ли что-то, что девайс в такой ситуации должен сделать без участия юзера?
- должен ли девайс помнить несколько беспроводных сетей? и автоматически приконнектиться к сети А, если сеть Б недоступна, но в текущих настройках была явно выбрана именно сеть Б?
Все перечисленное — маленькая часть сценариев, построенных только вокруг WiFi. Каждый из них сильно зависит от бизнес контекста. Например, мы не поддерживаем статические настройки сети, потому что вменяемые крупные кастомеры обычно не вбивают айпишники для сотен девайсов вручную
6/ Если мы хотим показать приложению или облаку статус WiFi соединения, то нужно вменяемое API (а значит, нужно собрать требования и придумать его так, чтобы в будущем не было мучительно больно). API предоставляется ОС, оно такая же часть продукта, как и все остальное
7/ Визуальная коммуникация (то, что пользователь видит на экране) — тоже часть операционной системы, которая пилится в тесной коллаборации с дизайнерами. Информация на экране, переходы состояний, success/failure messages и прочие красивости
8/ То, как работает LED — тоже визуальная коммуникация. Airtame показывает разный цвет для разных статусов (белый — idle, синий — streaming, медленно мигающий зеленый — update), и так далее. Естественно, этим тоже управляет ОС
9/ В целом, функциональность ОС можно поделить на:
- core внутренние функции, без которой девайс вообще не может существовать (точка доступа, networking, updater, factory reset, recovery, логика работы с HDMI). Это очень жирный и сложный кусок
- API, которое помогает consumer’ам (application/Cloud) запрашивать или аплоадить настройки, получать текущий статус разных компонентов, забирать логи
- браузер + обвязка из плагинов, которые отвечают за то, чтобы показывать контент
- все для streaming'а
10/ При этом одни и те же юзкейсы даже для такой монументальной и базовой штуки, как ОС, можно придумать неправильно. Мой любимый пример, как делать не надо — updater.
11/ Изначально для апдейтера придумали чисто B2C-шную логику — дефолтный autoupdate on, сразу устанавливать все новые обновления, при этом показывать на экране процентики и в это время не давать ничего сделать с устройством
12/ Идея так-то хорошая и правильная:
- юзер всегда будет получать последнюю версию прошивки (а значит, получит все то добро, которые мы хотим нанести)
- на время апдейта девайс будет заблокирован для внешнего воздействия, чтобы минизировать риски того, что что-то пойдет не так
13/ Проблема в том, что у девайса несколько типов юзеров с конфликтом интересов.
Учитель, который использует девайс для мирроринга каждый день во время уроков, не будет обновлять девайс. Он вообще не думает про апдейт, ему нужно нажать кнопку и начать показывать урок
Более того, автоапдейт посреди дня легко может сорвать урок (потому что в зависимости от загруженности CDN, локальной сети школы и сигнала WiFi он может занять 10-15 минут)
В итоге админы стали отключать автоапдейты. Это немножко помогло, но админы в школах в основном в то же время, что и учителя, и часто не могли пушить апдейты руками из-за пересечения во времени. Поэтому некоторые девайсы оставались без апдейтов длительное время.
14/ Вывод — даже простой базовый кейс, который уже сделан в куче других продуктов, очень легко сделать через жопу :)
15/ Веселье с операционкой начинается, если продуктов в линейке становится больше одного, и делают они похожее, но хардварный стек (и возможности) отличаются от девайса к девайсу. Нужно красиво прятать под капотом кучу сложности, чтобы пользователь не почувствовал разницу
16/ Самое сложнодостижимое в операционной системе — стабильность. В случае с девайсами это очень критично :) зависшую программу перезагрузят, в глючащем зуме пересоздадут звонок. А девайс, который отвалился от сети, полезут резетить руками в 5-метровый потолок конференс холла
17/ Главная проблема в том, что ОС это очень сложная система, и самые злые проблемы по стабильности очень тяжело найти в in-house тестировании или в beta программе. На помощь частично приходит аналитика, но в целом это вечная борьба
18/ В остальном процесс работы над ОС не сильно отличается от других продуктов: стратегия -> цели -> приоритизация -> проработка темы/метрики -> декомпозиция -> итерации -> execution -> аналитика -> доставка