Сложно представить, что было бы с нашей компанией, потеряй мы все наши файлы: например, в результате пожара. Как минимум, довольно проблематично заниматься изданием настольных игр без их макетов, не говоря уже о тоннах других материалов, нужных для работы компании.
Поэтому ещё 5 лет назад, основав «Банду умников» и делая тестовый тираж, мы уже хранили все данные в Dropbox — благо они тогда умещались в бесплатные лимиты. За это время команда выросла с 2 до 35 человек, и в этом году мы поняли, что пора прощаться с Dropbox и переезжать на Google Drive. Это решение вызвало череду приключений, которые мы совсем не планировали.
Для переезда с одного облачного сервиса на другой может быть куча разных причин: от риска блокировок (привет, Роскомнадзор) до потребности в каком-то принципиально новом функционале. В нашем случае причина была простой: мы сели, посчитали и поняли, что вместо 12 аккаунтов с безлимитным хранилищем у нас может быть 35 аккаунтов (то есть вся команда) — и всё это ровно за те же деньги.
Но фраза «сказано — сделано» не случайно встречается только в сказках. Не то, чтобы мы думали, будто перенос всех данных состоится по щелчку пальцев, но всё же на берегу представляли себе переезд куда проще. А зря.
Вот 6 важных моментов, которые мы открыли для себя в процессе смены облачного провайдера.
1. За привычным порядком скрывается хаос
Когда 35 человек работают с какими-то данными, неизбежно появляются лишние файлы: дублированные или вовсе неактуальные. Со временем они множатся и распределяются относительно ровным слоем по всей структуре облачного диска.
Полбеды, если они заботливо сложены в папку «Макеты 2011 архив». В этом случае проще понять, что нужно, а что нет. Куда хуже, когда это «Новая папка (2)», а в ней файл «ааааааааааааасысыв.psd». Самостоятельно оценить, насколько конкретный файл важен, почти нереально: нужно каждый раз выяснять, кто пользуется тем или иным документом или папкой, насколько важно это хранить и переносить. Кроме этого, даже полезные и актуальные документы порой оказывались в неожиданных и неочевидных местах.
Поэтому мы попросили команду «причесать» существующую структуру данных: каждый брал свой блок и упорядочивал его в порядке от общего к частному, чтобы даже человеку, который никогда раньше не сталкивался с тем или иным документом, было понятно, где его найти: Актуальная общая информация Логотип и фирменный стиль Логотип (РУС и ENG).
После этой процедуры осталось куда меньше непонятных файлов и папок — их либо удаляли, либо помещали в общую структуру. Финальное структурирование всей библиотеки данных осуществляли в последнюю очередь, когда был наведён порядок в подразделах.
Важно, что наведение порядка — далеко не самая быстрая штука. Сначала мы распределяли зоны ответственности, потом проверяли логику новой структуры, что-то дорабатывали, разбирались с «бесхозными» файлами. Всё это делалось параллельно с текущей работой и заняло около трёх недель.
В результате мы получили максимально прозрачную и логичную структуру папок и избавились от 1/4 объёма файлов.
Но приключения только начинались.
2. Автоматической миграции не существует
После наведения порядка, нам предстояло перенести с Dropbox на Google Drive 3 терабайта данных. Первое, что пришло в голову: «Наверное, существует какой-то сервис, который позволяет сделать это автоматически — так, чтобы нажать на кнопку в пятницу вечером и пойти загорать».
Сперва нас очень воодушевили сервисы для миграции с одного диска на другой. Но когда мы поняли, что имеем дело со сложной структурой личных и командных папок, с которыми работают 35 пользователей с разным уровнем доступа — началось веселье. Получалась трёхмерная матрица:
- Список пользователей, которые участвуют в работе с данными;
- Структура доступа: к каким папкам имеет доступ тот или иной пользователь;
- Уровень доступа к той или иной папке: просмотр, комментирование, редактирование, передача прав и т.д.
В итоге мы поняли, что ни один из рассмотренных сервисов не позволяет перенести 3 Тб данных с сохранением структуры и уровней доступа. Более того, расчётное время «переезда» с помощью таких инструментов составляло несколько месяцев. Это нас категорически не устраивало.
3. Перенос данных — путь через тернии к звёздам
Мы арендуем хранилище в data-центре, который работает на серверной операционной системе Windows Server 2012. Оказалось, что, в отличие от Dropbox, Google Drive её не просто не поддерживает. Наше «гениальное» решение запустить процесс копирования напрямую оказалось технически нереализуемым на существующем ПО.
Тогда мы обратились к data-центру с просьбой: «Ребята, а вы можете развернуть на серверных мощностях образ Windows 10?» Партнёры удивились — судя по всему, наш запрос был не самым популярным. Им потребовалось время, чтобы поднять «десятку» на нашем пуле мощностей. Когда это удалось сделать, мы установили там две программы: Dropbox и Google Drive — в обеих залогинились под одним сотрудником, назначенным владельцем всех папок. Теперь можно было копировать данные.
Проблема была в том, что за раз (например, за одну ночь) невозможно было перенести все данные: процесс занимал минимум несколько недель. Если бы мы просто запустили перенос данных, дождались завершения и успокоились, мы бы получили в новом хранилище кучу неактуальной информации, потому что во время копирования папок в них ведётся работа: вносятся изменения в существующие файлы, создаются новые.
Поэтому за первый заход мы скопировали весь объём данных, актуальный на дату начала копирования, а потом с помощью программы xStarter ежедневно догружали только те файлы, которые были изменены или созданы. Программа видит новые файлы и обнаруживает изменения свойств всех ранее загруженных файлов, как бы подавая сигнал: «Файл создан, догрузи. Файл изменился, загрузи заново». Со временем догрузки становились всё меньше по объёму. Перед выходными мы перевели весь Dropbox в режим чтения, чтобы никто не внёс изменения, и запустили финальный перенос. Объём финальной догрузки составлял 20 Гб, вся процедура заняла несколько часов. Сравните с 3 Тб в начале.
Уже после переноса всех данных, мы заново настроили все параметры, связанные с доступом сотрудников к разным папкам и доработали структуру. В понедельник утром мы получили полностью актуальные структурированные данные на диске Google Drive.
4. Инструктаж — всему голова
Чтобы всем было понятно, как быстро начать работать с данными в новых условиях, мы сделали и опубликовали подробную инструкцию.
Вот основные её элементы:
• Новая структура папок, наглядно изображённая в Mindmeister. Чтобы разобраться, что где лежит, не приходилось копаться во всех папках — достаточно было посмотреть на карту. Плюс ко всему, новая структура файлов стала максимально логичной. На условном примере это выглядело так:
1. Полет в космос
1.1. Постройка ракеты
1.1.1. Архив ракет
1.1.2. Актуальная схема ракеты
1.2. Архив документации
1.3. Актуальный план-график запуска
• Инструкция по установке и работе с программой Google Drive.
• Основные отличия в работе Google и Dropbox, чтобы позже они не стали неожиданным открытием.
• Правила работы с личными и общими папками.
Инструкция позволила ответить на 90% возникающих вопросов и существенно сэкономить время: как тех, кто мог бы озадачиться вопросом, так и тех, кому бы предстояло отвечать.
Всё, хэппи энд? Как бы не так!
5. Если не контролировать поток данных, начинается давка
В первый же день работы в Google Drive выяснилось: мы не учли заранее, что ребятам нужно иметь у себя часть данных в офлайн-режиме, а не в виде ссылок на файлы в облаке — например, тяжёлые макеты. Когда дизайнеры стали одновременно грузить себе в папки все исходники и макеты, нашему интернет-каналу стало плохо. Очень плохо. Часть процессов в компании просто встала — не работала даже 1C. Теперь, оглядываясь назад, мы понимаем, что нам следовало предпринять заранее:
A. Договорится с ребятами о щадящем графике загрузки. Главное правило: не грузить всё и сразу. Сначала только те файлы, с которыми прямо сейчас работаем, потом следующие по приоритетности, и так далее. По возможности делать это ночью или на выходных.
B. Заранее попросить сисадмина настроить квоты на сетевом оборудовании, когда у каждого есть своя гарантированная полоса. Это позволяет исключает ситуацию, когда из 100 Мбит канала 90 сразу забирают трое дизайнеров, а остальные 32 человека вынуждены делить 10 Мбит.
C. Попросить того же сисадмина сделать расписание допустимых загрузок. К примеру, ночью всем можно качать данные с диска без ограничений, а днем только по полосам.
D. Настроить приоритет трафику. Допустим, VOIP и RDP подключения сдалать самыми приоритетными, чтобы всегда работал скайп и удалённые сервера. Важная деталь: не всё сетевое оборудование имеет такую опцию. Для этих целей мы выбрали оборудование MikroTik и без проблем всё настроили.
6. Неисповедимы пути Google Drive
В первые дни работы выяснилась ещё одна неприятная особенность, после обнаружения которой мы точно будем вдвое внимательнее проверять всё ПО перед запуском. Когда мы включали оффлайн-доступ к папке или файлу в программе Google Drive, весь кэш сохранялся… только на диске «C». Возможность выбора в настройках диска для сохранения кэша отсутствовала.
Не беда, если это 10 текстовых документов, с которыми работает копирайтер. Проблемы начинаются, когда нужен офлайн-доступ к макетам и исходникам видео, каждый из которых может весить гигабайты. В итоге у дизайнеров кэш всех файлов падал на маленький SSD-диск с системой. При его объёме 250 Гб это быстро приводило к переполнению, а диск «D» на 4 Тб оставался незадействованным в этом процессе.
Позже выяснилось, что Google Drive только недавно реализовал функцию, позволяющую изменить место хранения кэша тех файлов, которые находятся в оффлайн-доступе — с диска «C» на диск «D». Возможность внести изменения есть только у администратора, который для этого запускает специальную команду в редакторе реестров — а отдельный пользователь по-прежнему не имеет такой возможности.
Вывод простой: перед принятием решения о запуске нового ПО, его следует внимательно и многократно тестировать во всех рабочих сценариях.
Три коротких вывода
1. Выбор подходящего облака — жизненно важная штука.
Здесь надо внимательно взвесить все за и против: изучить тарифы, софт и функционал. В случае ошибки и последующего разочарования в выборе можно «попасть» на переезд. А это, мягко говоря, нетривиальная процедура, которая может заморозить всю работу и повлечь за собой немалые затраты.
2. Полезно всегда держать файлы в порядке и на всякий случай иметь план «B».
Потребность в переезде может возникнуть неожиданно: Роскомнадзор начнёт накрывать вашего провайдера свинцовой кастрюлей, или изменятся тарифы — причин может быть море. К тому же, с логичной структурой файлов просто удобно и приятно работать.
3. Переезд — это не только про технику, но и про команду.
Все манипуляции с переносом файлов и наведением порядка могут обернуться полным провалом, если не держать команду в курсе и действовать по принципу «разберутся как-нибудь сами». Может и разберутся, но без прозрачного и заботливого инструктажа работа этот процесс будет куда более трудозатратным и изматывающим.
Автор: Anton Semenov
