Як ми створили застосунок, що інформує про життєдіяльність офісу під час блекаутів

Усі статті, обговорення, новини про Mobile — в одному місці. Підписуйтеся на телеграм-канал!

Привіт! Мене звуть Дмитро Панін, я Delivery Director у Levi9. В цій статті я хотів би поділитися досвідом створення та імплементації вебрішення в компанії, яке допомогло дещо полегшити життя команди в умовах блекаутів.

Насамперед почну з того, що це рішення дуже допомагало впоратися з викликами, пов’язаними з цілковитими відключеннями взимку. Проте Monitor9 залишається актуальним і зараз, а також не забуваємо, що нам в умовах воєнних дій слід бути готовими до будь-яких катаклізмів, тому про особливості нашого рішення — далі.

Хоч би як мені не хотілося знову думками повертатися до перших місяців повномасштабного вторгнення, але 24 лютого 2022 року змінило все. Після цього життя кожного українця розділилося на «до» та «після», тож згадок і розмов про це не оминути. На роботу нашої компанії, як і всіх бізнесів в Україні, суттєво вплинули блекаути, тож ми шукали рішення, яке б допомогло легше адаптуватися. Так народилася ідея внутрішньої розробки для нотифікації команд.

Трохи передісторії

У Львові перші блекаути настали в травні 2022 року через ракетні атаки росії. У жовтні 2022 року у Києві та Львові через влучання було пошкоджено об’єкти критичної інфраструктури, а люди лишилися без світла, інтернету й води. За таких умов компанія не могла залишитись осторонь та вирішила підтримати співробітників і допомогти їхнім сім’ям пережити цей складний період.

Звісно ж, паралельно з операційною підготовкою, як-то закупівлею малих зарядних станцій, створенням запасу води в офісі, встановленням генераторів тощо, необхідно було продумати, як інформувати колег про роботу та устаткування офісу: чи є світло, вода, опалення, інтернет, як дати можливість підживити домашню зарядну станцію чи навіть прийняти душ і випрати речі.

Тому вирішили створити невеликий вебзастосунок з короткою інформацією про стан систем в обох офісах.

Основні зони фокусування

Реалізувати задумане рідко вдається без сюрпризів — то вимоги змінюються, то незрозуміло, звідки отримати дані, то інтеграція зі сторонньою системою виявляється складнішою, ніж очікували.

У випадку з нашим вебзастосунком треба було враховувати ще й контекст, у якому він створюється, та обмеження з боку користувачів, на які неможливо впливати.

Челендж 1: PWA

Ми хотіли зробити рішення, яке б працювало як онлайн, так і при дуже слабкому стільниковому зв’язку.

Врешті-решт вирішили розробляти Progressive Web Application — вебзастосунок з можливістю його встановлення як нативного. Завдяки цьому його можна легко завантажити, встановити та використовувати за різних умов.

Всі оновлення даних у застосунку вирішили виконувати вручну задля максимального збереження заряду пристроїв користувачів. Так само відмовилися і від нотифікацій всередині PWA застосунку.

Челендж 2: максимально легкий застосунок

Як всі знають, одна з проблем під час блекаутів — це часткова чи майже повна відсутність зв’язку. В кого був оптоволоконний інтернет, могли якимось чином бути online, проте решта ж мала перемикатися на мобільний зв’язок, який залежить від рівня заряду акумуляторів на базовій станції мобільного оператора.

І якщо спочатку це відчувалося не сильно, бо 3G/4G більш-менш витримував до 4 годин, то згодом період роботи стабільного мобільного інтернету сильно знижувався, акумулятори не встигали заряджатися, тож зв’язок був у кращому випадку до двох годин.

Враховуючи це, наш застосунок мав складатися з мінімальної кількості компонентів для подальшого завантаження користувачем. Водночас кожен з компонентів повинен якомога менше важити, і, звісно ж, клієнтська частина має кешуватися на стороні користувача для пришвидшення роботи.

В результаті вирішили повністю відмовитися від будь-яких фреймворків і писати вебчастину застосунку на чистих HTML, CSS, JavaScript.

Челендж 3: Відмовостійкість

Відсутність світла та зв’язку накладає обмеження на те, як користувач отримуватиме доступ до інформації, а також на доступність застосунку щодо хостингу при різному фізичному розташуванні застосунку та його дистрибуції назовні.

Відтак, розташовувати хостинг застосунку на внутрішніх серверах Levi9 було недоцільно, адже вони теж залежать від наявності світла та інтернету.

У результаті вирішили хостити застосунок у хмарі.

Челендж 4: Обмеження доступу

Треба було потурбуватися і про обмеження доступу та зручне користування застосунком.

Оскільки сам застосунок та інформація в ньому створювалися виключно для спеціалістів компанії, доступ до нього лімітований засобами внутрішньої інфраструктури.

Реліз застосунку та інкрементальні покращення

Час йшов, блекаути ставали все більшою проблемою, така система була просто необхідна. Ми вирішили бути гнучкими та викотити реліз Monitor9 як мінімально життєздатний продукт (своєрідний MVP), який покриває основні потреби й водночас дає можливість отримати відгук від реальних користувачів. Так ми могли б зрозуміти, як розвивати та вдосконалювати продукт надалі.

Таким чином на світ з’явилася перша версія застосунку. У ній користувачі могли побачити, чи є у конкретному офісі світло, інтернет від основного провайдера чи можна скористатися резервним StarLink-ом. Також була інформація про наявність води та опалення в офісах.

До речі, MVP нам вдалося викотити не настільки швидко, як хотілося: через певні внутрішні процеси та відсутність світла й звʼязку у самих розробників нам знадобилося близько 3 тижнів, з яких 1 спринт зайняла виключно автоматизації сповіщень.

Багато часу зайняло вибудовування автоматизованого процесу отримання та відображення даних по воді та температурі повітря — нам треба було зробити IoT девайси: дочекатися комплектуючих, а потім протестувати, зінтегрувати з внутрішньою інфраструктурою та, зрештою, з самим застосунком.

А вже після релізу додали development environment, адже треба було тестувати інкрементальні зміни до того, як вони з’являться на проді.

Пристрої робили самостійно. При цьому їх корпуси ми видрукували на 3D-принтері, що стоїть в київському офісі, та розробили програмне забезпечення. Решта компонентів, як-то датчики, мікроконтролери, адаптери живлення були вже готовими й нам треба було з’єднати все воєдино. Щоб опитувати датчики ми обрали одну з популярних плат розробки на базі esp8266. Вони мають WiFi-підключення, доступні та добре описані.

Розробили 2 типи пристроїв:

• Для моніторингу температури повітря та вологості (поки що показуємо лише температуру). Їх ми розташували в частинах офісів, де показники по температурі середні.
• Для моніторингу тиску води. Цих пристроїв ми також зробили декілька екземплярів — для моніторингу кожної окремої точки входу.

Виклики на шляху

Життя за постійних блекаутів і з врахуванням графіка відключень світла стало нормою, тому важливо було інформувати людей про актуальний статус послуг та його зміну максимально швидко.

Треба було знайти рішення щодо регулярного та автоматизованого сповіщення користувачів. Не обійшлося без викликів, які призвели до модифікації вебзастосунку.

Рішення 1: коли відсутній зв’язок

Одним з каналів інформування мав стати Outlook — щоб автоматизувати роботу офіс-менеджерів, які власноруч щоранку мали інформувати команду про умови роботи чи давати апдейти, коли щось змінювалось.

І тут з’явився ще один виклик: що робити, коли світло чи інша послуга в офісі зникли, а людина вже в дорозі — вирішили цей момент використанням одного з популярних месенджерів.

Крім того, не потрібно додаткових зусиль: у більшості співробітників вже все встановлено на власних пристроях.

Рішення 2: коли забагато повідомлень

Але з іншого боку, іноді повідомлення втомлюють і люди перестають на них реагувати.

Коли ситуація більш-менш стабілізувалася, регулярні сповіщення перестали приходити щоранку в робочі дні. Тепер користувачі їх отримують лише коли один з сервісів недоступний.

Рішення 3: коли на генераторі

Наступним покращенням стала інформація про джерело електроенергії. До цього моменту застосунок лише показував, що світло є, але не зазначав, чи воно подається від генератора.

Це важливо, адже тоді навантаження в офісі обмежене, що призводить до певних незручностей. Для цього ввели статус «На генераторі» і додали його до сповіщень.

IoT

Перші версії застосунку отримували інформацію про наявність води та тепла у ручному режимі, що сильно обмежувало швидкість оновлення даних і їх актуальність. До того ж інформація надавалася для всього офісу, не враховуючи особливості інфраструктури поверхів кожного з офісів.

До речі, в процесі розробки застосунку ми вирішили не ускладнювати функціонал, а навпаки, спростити — певна еволюція 🙃. Так, ми спочатку думали, як автоматизувати відображення відсутності/ наявності опалення, а потім прийшли до того, що краще вже працювати з поточною температурою і не ускладнювати бізнес-логіку.

Для автоматизації отримання даних про наявність води на поверхах, а також поточної температури повітря в офісах, вирішили використати сенсори з підключенням до мікроконтролерів. Таким чином вдалося отримати інформацію про наявність води на кожному з входів у офіси, а також температуру повітря на декількох поверхах, незалежно один від одного.

Плани на майбутнє

Останнім не автоматизованим елементом у застосунку лишається інформація про джерело живлення офісів — централізоване воно чи від генератора. На щастя, гострої потреби в автоматизації цього моменту наразі немає. Однак, це буде головним елементом змін у майбутньому.

Ми завжди відкриті до будь-яких ідей від наших колег про те, як покращити застосунок та які дані можуть бути потенційно корисними у ньому.