Два в коробці (якщо можна) і всі в документації (завжди).
У контексті ІТ «два в коробці» означає два сервери або компоненти, які призначені для спільної роботи, щоб забезпечити резервування та підвищену надійність. Це налаштування може гарантувати, що якщо один компонент виходить з ладу, інший візьме на себе його операції, таким чином зберігаючи безперервність обслуговування. Мета «двох у коробці» — забезпечити високу доступність і аварійне відновлення. Це також стосується ролей людини в організації; однак це рідко реалізується.
Давайте розглянемо відповідний приклад Analytics. Ми всі, ймовірно, знаємо людину в нашій компанії чи організації на ім’я, до якої звертається Analytics. Це ті, хто має звіти або інформаційні панелі, названі на їхню честь – Звіт Майка або Інформаційна панель Джейн. Звичайно, є й інші люди, які знаються на аналітиці, але це справжні чемпіони, які, здається, знають, як виконувати найскладніші речі та перевищувати терміни. Справа в тому, що ці люди самотні. У багатьох випадках під тиском вони не працюють ні з ким, оскільки це може їх уповільнити, і тут починається проблема. Ми ніколи не думаємо, що втратимо цю людину. Я утримаюся від типового «скажімо, їх збив автобус» або використання прикладу, що використовує поточні можливості на ринку праці, і скажу щось позитивне на зразок «вони виграли в лотерею!», тому що ми всі повинні зробити свій внесок, щоб бути позитивними ці дні.
Історія
Настає ранок понеділка, і наш експерт з аналітики та чемпіон MJ подав заяву про відставку. MJ виграв у лотерею і вже залишив країну без жодної опіки. Команда та люди, які знають MJ, схвильовані та заздрять, але робота має тривати. Це момент, коли цінність і реальність того, що робив MJ, ось-ось стане зрозумілою. MJ відповідав за остаточну публікацію та перевірку аналітики. Здавалося, що вони завжди могли підвищити ефективність або внести такі складні зміни, перш ніж надати аналітику всім. Нікого насправді не хвилювало, як це було зроблено, і він був упевнений у тому факті, що це просто сталося, а MJ був індивідуальною рок-зіркою Analytics, тому був наданий певний рівень автономії. Зараз, коли команда починає збирати частини, запити, щоденні проблеми, запити на модифікацію, вони губляться й починають сваритися. Звіти / інформаційні панелі знаходяться в невідомому стані; деякі ресурси не оновлювалися протягом вихідних, і ми не знаємо чому; люди запитують, що відбувається і коли все буде виправлено, правки, які MJ сказав, що зроблено, не з’являються, і ми не маємо уявлення, чому. Команда виглядає погано. Це катастрофа, і тепер ми всі ненавидимо MJ.
Уроки
Є кілька простих і очевидних висновків.
- Ніколи не дозволяйте людині працювати наодинці. Звучить добре, але в менших гнучких командах у нас немає часу чи людей, щоб це зробити. Люди приходять і йдуть, завдань багато, тому розділяй і володарюй в ім’я продуктивності.
- Кожен повинен ділитися своїми знаннями. Звучить добре, але чи ділимося ми з потрібною людиною? Майте на увазі, що багато переможців лотереї є колегами. Сеанси обміну знаннями також віднімають час від виконання завдань, і більшість людей інвестують у навички та знання лише вчасно, коли це необхідно.
Отже, які є реальні рішення, які кожен може реалізувати та відступити?
Почнемо з керування конфігурацією. Ми використовуватимемо це як загальний термін для кількох подібних тем.
- Управління змінами: Процес планування, впровадження та контролю змін програмних систем у структурований та систематичний спосіб. Цей процес має на меті гарантувати, що зміни вносяться контрольованим та ефективним способом (з можливістю повернення), з мінімальним порушенням існуючої системи та максимальною вигодою для організації.
- Управління Проектом: Планування, організація та контроль проектів розробки програмного забезпечення, щоб гарантувати, що вони завершені вчасно, у межах бюджету та відповідно до бажаних стандартів якості. Це передбачає координацію ресурсів, діяльності та завдань протягом життєвого циклу розробки програмного забезпечення для досягнення цілей проекту та доставки програмного продукту за розкладом.
- Безперервна інтеграція та безперервна доставка (CI/CD): Процес автоматизації створення, тестування та розгортання програмного забезпечення. Безперервна інтеграція вимагає регулярного об’єднання змін коду в спільне сховище та виконання автоматизованих тестів для виявлення помилок на ранніх стадіях процесу розробки. Безперервна доставка/розгортання включає в себе автоматичний випуск перевірених і підтверджених змін коду у виробництво, що дозволяє швидко та часто випускати нові функції та вдосконалення.
- Контроль версій: Процес керування змінами вихідного коду та інших артефактів програмного забезпечення з часом за допомогою спеціалізованих програмних засобів. Це дозволяє розробникам співпрацювати над кодовою базою, підтримувати повну історію змін і експериментувати з новими функціями, не впливаючи на основну кодову базу.
Усе вищезазначене стосується належної практики розробки програмного забезпечення. Аналітика, яка стимулює та керує бізнесом, заслуговує не менше, оскільки вона є критично важливою для прийняття рішень. Усі аналітичні ресурси (завдання ETL, семантичні визначення, визначення показників, звіти, інформаційні панелі, історії… тощо) — це лише фрагменти коду з візуальним інтерфейсом для проектування, і, здавалося б, незначні зміни можуть завдати шкоди роботі.
Використання керування конфігураціями дозволяє нам підтримувати роботу в належному стані. Активи мають версії, щоб ми могли бачити, що сталося протягом їхнього життєвого циклу, ми знаємо, хто над чим працює, а також досягнутий прогрес і часові рамки, і ми знаємо, що виробництво триватиме. Те, що не охоплюється жодним чистим процесом, так це передача знань і розуміння того, чому все відбувається так, як воно є.
Кожна система, база даних і інструмент аналітики мають свої особливості. Речі, які змушують їх рухатися швидко або повільно, предмети, які змушують їх поводитися певним чином або давати бажаний результат. Це можуть бути налаштування на системному чи глобальному рівні або речі в дизайні активів, які дозволяють їм працювати так, як вони повинні. Проблема в тому, що більшість із цих речей вивчаються з часом, і не завжди є місце, щоб їх задокументувати. Навіть коли ми переходимо до хмарних систем, де ми більше не контролюємо, як виконується програма, і ми покладаємось на постачальника, щоб зробити це якомога швидшим, налаштування визначень продовжується в наших активах, щоб розблокувати саме те, що ми шукаємо. Ці знання – це те, що потрібно фіксувати та ділитися, роблячи їх доступними для інших. Ці знання повинні вимагатися як частина документації активів і бути невід’ємною частиною контролю версій і перевірки CI/CD і процесу затвердження, а в деяких випадках навіть як частина контрольного списку перед публікацією речей, які потрібно зробити, а не робити.
Немає магічних відповідей чи штучного інтелекту, щоб прикрити ярлики в наших аналітичних процесах або їх відсутність. Незалежно від розміру команди, яка забезпечує обробку даних і аналітику, інвестиції в систему для відстеження змін, версії всіх активів і допомоги в документуванні процесу розробки та збору знань є обов’язковими. Інвестиції в процеси та час на початку заощадять масу втраченого часу на з’ясування речей, щоб підтримувати здоровий стан нашої аналітики. Трапляються речі, і краще мати страховий поліс для MJ та інших переможців лотерей.
