Поэтому ещё 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. Переезд — это не только про технику, но и про команду.
Все манипуляции с переносом файлов и наведением порядка могут обернуться полным провалом, если не держать команду в курсе и действовать по принципу «разберутся как-нибудь сами». Может и разберутся, но без прозрачного и заботливого инструктажа работа этот процесс будет куда более трудозатратным и изматывающим.
Комментарии (84)
remzalp
28.05.2018 12:17+2Позже выяснилось, что Google Drive только недавно реализовал функцию, позволяющую изменить место хранения кэша тех файлов, которые находятся в оффлайн-доступе — с диска «C» на диск «D».
К счастью, в случае с Windows можно смонтировать раздел жесткого диска в каталог штатными средствами. Будет не очень гибко, но вполне надёжно.
ximik13
28.05.2018 12:36-1Вот только знают об этом обычно только админы, работавшие с Unix подобными системами :).
remzalp
28.05.2018 12:40
Мне кажется многие админы видели это больше одного раза в жизни в управлении дисками. Что особенно приятно, у одного раздела может быть и имя диска и несколько смонтированных путей.
acyp
28.05.2018 12:36Или SoftLink C:\Temp-->D:\temp. Например. Актуально как для Виндовс, так и для linux-машин.
ReDisque Автор
28.05.2018 12:42+1Софтлинк да — пробовали, повел себя неадекватно на ряде машин. Поддержка Гугла рекомендовала через реестр править. Вообще конечно полный бред с их стороны такой подход
GamePad64
28.05.2018 14:55В NTFS есть помимо симлинков ещё и junction, который можно создать через
mklink /J. В некоторых случаях, он работает стабильнее, чем софтлинки.
RiseOfDeath
28.05.2018 14:44По моему личному впечатлению на винде (покрайней мере на 2012 сервере) симлинки (Вы это под софтлинком подразумеваете? Который через mklink делаются) работают как-то странно. Вроде бы в «Проводнике» все норм, но у некоторых программ возникают проблемы при работе через симлинки. Причем проблемы из разряда «уууу шайтанама, че-то не работает».
ALF_Zetas
28.05.2018 16:37начиная с десятки RS3 всё наоборот — junction стали работать значительно хуже и пришлось их все передельівать в симлинки
Beaglz
28.05.2018 12:46Понятно, что вы хотели сэкономить, но получилось ли — не факт.
Как обрабатываются коллизии — очень интересный момент, на нем стоит заострить внимание при выборе хранилища. ЯД, например, одно время избирательно синхронизировал файлы, из-за чего возникали постоянные проблемы с актуальностью данных у разных пользователей, а то и копии плодились.
Пока вы настраиваете квоты из-за GD, у DB есть синхро внутри LAN, что существенно снижает нагрузку при обмене макетами внутри офиса. Вероятно, что вы обратно не вернетесь, но это явный плюс DB.
И немного больше порядка с файлами позволит навести простой трюк с датой создания в начале имени файла/папки в формате ГГГГММДД, например.ReDisque Автор
28.05.2018 12:50у DB лан синхронизация — вещь, меня одно утешает, что в сам File Stream был выпущен сравнительно недавно, и будет дорабатываться.
Taciturn
28.05.2018 12:50который работает на серверной операционной системе Windows Server 2012. Оказалось, что, в отличие от Dropbox, Google Drive её не просто не поддерживает.
Удивительно это читать — вы знаете о Google, но даже не попробовали его использовать для решения проблемы. По запросу «Google Drive File Stream Windows Server» (скопировано из ошибки, которую пишут установщик при попытке установить штатно) первая же ссылка ведёт на reddit, где написано как же всё таки установить Drive на сервер.ReDisque Автор
28.05.2018 13:07если говорить о личных штуках -я так и делаю, даже нравится, самому «наколхозить» и взломать систему :) а если говорить о корп. решениях, я стараюсь до последнего решить вопрос стандартными методами. Могу даже объяснить почему.
slaFFik
28.05.2018 19:45Да, объясните, пожалуйста. Интересно "корпоративное" мышление в этом случае.
ReDisque Автор
28.05.2018 21:21+1Основной момент в делегировании полномочий. Когда бизнес быстро растет, а мы выросли с 2 человек до 40 фактически за 3 года, ты почти каждый день должен отдавать по кусочкам свои задачи кому-то, кому ты очень доверяешь и кого ты хорошо подготовил. Так вот, зачастую не получается просто делегировать напрямую, нужно искать компромисс, потому что мы очень жестко контролируем издержки. Допустим, я научил нашего офис менеджера оперировать понятиями SSD диск, память, объяснил чем отличаются конфигурации ПК для разных сценариев и т.д. И она, как сообразительный сотрудник, вполне может сама с этим управляться, без меня, заказывать нужные железки, объяснять сотрудникам что происходит с их ПК, подключать удаленного сис. админа если все варианты исчерпаны и надо апгрейдиться. Тут тоже самое — мы не хотим брать выделенного сис. админа который 70% времени будет сидеть, причем объективно, ничем не занятый. Мы используем аутсорс + прокачку сотрудников по базовым навыкам IT и вот тот колхоз, что я написал выше, он уже «слишком» для основных сотруднико. За гранью, это будет перегруз — я лучше сделаю чуть более длинным путем, но зато, например, они смогут прочитать все в официальной тех. поддержке гугла или слака. И выиграют все: меня, как руководителя и эксперта в этой области не будут дергать, они сами расширят свой проф. кругозор, а пользователь, кто запрашивал эту услугу останется доволен, а компания еще и сэкономит.
Massacre
29.05.2018 07:04+1Итого: на сисадмине сэкономлено, зато данные компании — в заложниках у сторонних облачных сервисов. Вы их хоть бэкапите локально?
vesper-bot
28.05.2018 13:07Когда мы включали оффлайн-доступ к папке или файлу в программе Google Drive, весь кэш сохранялся… только на диске «C».
Позже выяснилось, что Google Drive только недавно реализовал функцию, позволяющую изменить место хранения кэша тех файлов, которые находятся в оффлайн-доступе — с диска «C» на диск «D».Оу мама. И это в 2018 году! Формально, самое правильное место для кэша — %APPDATA%, которая располагается в подпапке профиля, который по-хорошему надо уносить с системного диска при заливке ОС (или сразу после), и если этого не было сделано, то ребята ССЗБ. Фактически, оффлайн-кэш лучше с точки зрения пользователя хранить в подпапке Documents с соответствующим приложению именем (а-ля "Google Drive — username"), а вот её уже перенести на соседний диск куда легче, и с этим справится и пользователь без админских прав, если на диске с данными у него есть право create subfolder. Хорошо, что сделали правильный вывод :)
ReDisque Автор
28.05.2018 13:11+1Кхм, вариант. Мнтересно, а что будет с производительностью других приложений которые хранят там данные? Например кеш Адоба у дизайнеров, где очень критична скорость?
stetzen
28.05.2018 13:24Даже Адоба не надо — кэш браузера, лежащий на HDD, ошутимо замедляет работу этого самого браузера.
vesper-bot
29.05.2018 09:42Ну как вариант, подпапку %APPDATA%\Local\Adobe смапить обратно на C:. Иначе получается старая песня, или быстро, или много, но не оба сразу.
MaxMator
28.05.2018 14:293. Перенос данных — путь через тернии к звёздам
Делается одной простой командой:
robocopy "D:\nsr\index" "Y:\new_place\index" /MIR /NFL /MT
Сам часто переношу данные которые не статичны
Причем её можно обрывать, запускать заново и т.д.
И будет лишь «докатывать» новые и измененный файлы.
paranoya_prod
28.05.2018 15:09Сколько отделов в компании использовало Дропбокс? Переезжали сразу все?
PS. За «ааааааааааааасысыв.psd» в общем хранилище надо наказывать лишением доступа к чайнику.ReDisque Автор
28.05.2018 15:39у нас нет отделов как таковых, есть общая команда 35-40 человек.
paranoya_prod
28.05.2018 16:02То есть, все занимались всем и никакого разделения на проекты или типу выполняемых работ?
ReDisque Автор
28.05.2018 16:38Нет у нас несколько десятков проектов и команда работает по проектно, собирая под каждую задачу свою комбинацию сотрудников
paranoya_prod
28.05.2018 17:33Понятно. То есть, можно было пару проектов сначала перевести на Гуглодиск и протестить.
Filex
28.05.2018 15:10Я правильно понял, что программа xStarter — это программа для автоматизации действий на ПК?
madvlaydin
28.05.2018 15:39есть же cvs, которые умеют отслеживать бинарники и проприетарные форматы, кто-нибудь пробовал прикрутить управление версиями не к текстовым документам?
так-то репозиторий поднять нынче просто оченьalan008
28.05.2018 20:56+1Репозиторий на 3 Тб под большие бинарные файлы — так себе идея. Особенно если эти файлы часто редактируются.
BalinTomsk
28.05.2018 16:22— что вместо 12 аккаунтов с безлимитным хранилищем у нас может быть 35 аккаунтов (то есть вся команда) — и всё это ровно за те же деньги.
Я думаю что если бы позвонили в маркетинговый птдел dropbox-a вы вполне могли бы договорится получить тоже самое за те же деньги и сэкономить на переезде.ReDisque Автор
28.05.2018 16:40Я думал, но там тоже есть нюансы, мы, например, клиенты gsuite и нам выгоднее все консолидировать. Сейчас думаем отказаться от подписки на офис, т.к. есть все в гугле. И потом, я очень расстроился за маркетинг дропбокса, что когда их клиент с почти 5-ти летней историей прекращает работать, мне даже формального вопроса не задали — а почему? Что случилось? Так буднично — хоп, отключили и через два дня вернули деньги. Я полагал, что они будут цепляться.
BalinTomsk
28.05.2018 21:11Мне кажется какие-то глобальные полиси стали менятся — раньше когда я закрывал счета и кaрточки в банках — обязательно спрашивали почему и уговаривали это не делать.
И мне приходилось себя сдерживать, чтобы не наговорить необдуманных гадостей про их «сервис». Сейчас — повсеместный молчек. Что не может не радовать.
davydt
28.05.2018 16:40Не увидел какого-либо резервного копирования. Если гугл в результате аварии / санкций заблокирует ваши данные — что будете делать?
Второй вопрос — неужели нельзя купить какую-нибудь Synology (если уж не хочется нанимать сисадмина) и поставить ее в офисе? Чтобы не качать рабочие данные туда-сюда. Бекап можно сделать куда угодно.ReDisque Автор
28.05.2018 16:45по первому пункту — они выкатили на днях функцию экспорта: gsuiteupdates.googleblog.com/2018/05/export-all-your-g-suite-data-in-one-step.html мы готовимся на нее перейти, но пока не понятно что с драйвом. Была еще задумка оставить один акк дропа, с безлимитом и туда на сервере перекладывать данные как-то. Но у дропа нет таких акков, максимум 1 Тб. Короче вопрос в процессе решения.
Меня очень парит вопрос безопасности, ну кому мешает прийти в офис и забрать этот синолоджи? А пожар, а потоп и т.д. Везде есть свои плюсы и минусы.davydt
28.05.2018 16:48Меня очень парит вопрос безопасности, ну кому мешает прийти в офис и забрать этот синолоджи?
Можно зашифровать.
А пожар, а потоп и т.д. Везде есть свои плюсы и минусы.
Если данные дороги — всегда нужно бекапить в другое местоположение. Хоть облако, хоть локальное железо. На данный момент у вас это не реализовано.
madvlaydin
28.05.2018 16:49так-то во всех айтишных конторах есть свои серверные помещения, где стоят стойки с дорогущим оборудованием (серверным и телекоммуникационным), и ведь не боятся же, что кто-то придёт и заберёт.
плюс никто не отменяет хранить вашу инфу в офисе и сливать в облако.
всяко лучше чем хранить только в облаке или только локально в офисе.vozhd99
28.05.2018 17:54Причём решений достаточно много: от самых недорогих до дорогих. Мы решили юзать принцип: храним бэкапы в офисе + раз в неделю крайний заливаем в облако.
GoodGod
28.05.2018 17:53Считаю важным сказать, что необходимо присмотреться к вопросу бэкапа, вот статья
habr.com/post/262043
как Amazon EC2 потерял данные клиента
Tyusha
28.05.2018 18:22Названия папок и файлов у нас, например, строго регламентированы. Файл с непонятным названием удаляется без разговоров первым заметившим непорядок — извини, ничего личного. Очень дисциплинирует, надо сказать. Если нужен файлик aaaaa.psd сохраняй его локально, хоть на рабочий стол, в общем каталоге испражняться не надо.
ReDisque Автор
28.05.2018 18:25а вы не поделитесь правилами? ) очень интересен опыт других в этой части
ElectroGuard
28.05.2018 19:55Странное немного желание хранить данные, которые нужны, как я понимаю, исключительно локально, в облаке. Поставили бы локальный NAS. 3тб сейчас на одном бердане даже бывают. И никаких проблем с миграцией. Для надёжности можно добавить зеркало + инкрементные бакапы. В чём профит от облаков в вашем случае? Кроме описанных неудобств, хорошо если последних?
ReDisque Автор
28.05.2018 21:25Безопасность и надежность, любое облако от большой компании априори надежней в выборе между: только облако или только локально. Нам просто не потянуть такой уровень безотказности и надежности внутри компании. Мы объективно оцениваем риски. и я жду все же локальной синхронизации от Гугл как это было в Дропе. Это решит все вопросы.
ElectroGuard
28.05.2018 22:00Облако далеко не панацея. Завтра выйдет очередной чудный закон наподобие Яровой, GDPR, блокировки и так далее. И хорошо, если данные вообще можно будет забрать. Локально же поставить сервер дело нескольких дней. 3тб на сервере сейчас это уже вообще ничто, согласитесь. Небольшой сервер на несколько жестких. Мне кажется проблема несколько надумана. Не те объемы совсем. Я понимаю, ну хотя бы о сотне тб разговор шёл. И не в будущем, а сейчас прямо.
ReDisque Автор
28.05.2018 22:12У нас уже готов собственный впн сервер вне России, и часть трафика уже туда «заворачивается», в крайнем случае мы готовы завернуть весь. Поэтому мы тут тоже подстраховались, хотя все это конечно дико неудобно для всех.
Tyusha
29.05.2018 09:35Чтобы хранить информацию своими силами необходим квалифицированный сисадмин. А чтобы гарантировать её сохранность нужен очень квалифицированный сисадмин. Плюс ПО и оборудование. Кроме того, никто не застрахован от пожара, потопа и ОБЭП. Не строить же распределённую систему. Поэтому облачное хранилище на порядки дешевле описанной схемы.
acyp
29.05.2018 09:48Про порядки — это вы изрядно прибавили (см приближенные расчеты немного ниже по ходу обсуждения).
Про ОБЭП — давно уже изъятия не встречал, их интересует бухгалтерия, но даже в этом случае чаще всего удовлетворяются последним бэкапом хотя бы недельной давности. Ну или при них его делаешь (Работаю в области 1с и говорю не со слухов, а практики).
Про админов — спасибо на добром слове, но тут скорее в архитектуру системы упирается. У нас в свое время архитектор нарисовал план, админы его реализовали. С тех пор состав админов поменялся процентов на 60, но все работает как часы — бэкап, мониторинг, проверки целостности и т.д.
ElectroGuard
29.05.2018 14:10Вы преувеличиваете, честно. Админов средней руки хватает. Привлечь, настроить и периодически (можно удалённо) поддерживать. Даже свой, постоянный, не нужен. Мы сами занимаемся изготовлением ПО в том числе для хранения некоторых специфических данных десятками и сотнями терабайт, знаю о чем говорю.
Massacre
29.05.2018 15:25Для гарантии сохранности достаточно сисадмина, знающего, что такое бэкапы, и да, их можно делать и в облако, желательно в несколько. Если проблема в ОБЭП, то это решается арендой сервера на удалённом хостинге, и, кстати, в статье упомянут такой сервер…
alexhott
28.05.2018 19:57А поднять свой файловый сервер? Три терабайта в наше время это небольшой размер,
ну для бэкапа еще. По крайней мере копирование будет несколько часов занимать вместо недель. Если хочется облако то виртуальный сервер арендовать.ReDisque Автор
28.05.2018 21:23наш прогноз что данные будут расти по экспоненте, удваиваясь каждый год как минимум. локальное решение так себе.
rPman
28.05.2018 21:5935 человек, работающие с большими файлами, положат дешевый сервер на ура, а ssd на 3 терабайта кусаются.
ReDisque Автор
28.05.2018 22:13да, или собирать какие-то рейды, а это недешево :(
acyp
29.05.2018 04:19Неожиданный аргумент. Давайте посчитаем в некоем приближении — стоечная дисковая полка от НР с дисками на сегодняшний объем на райд10 — около 120к.руб (понятно, что бу, но как показывает практика — надежность при грамотном выборе не страдает), сервер для OwnCloud (это если совсем по взрослому играть) в районе 70-100 к.руб. При этом его можно грузануть сторонними задачами типа проксирования, поддержки своего веба и т.д.
Если хотим конкретно сэкономить — то просто отказываемся от сервера ОвнКлоуд. Простых виндовых шар часто оказывается достаточно. особенно при налаженной системе бэкапа. в дисковую полку размер бэка заложен.
Расширение объемов этого наколеночного чуда — в районе 15 к.руб за Тб. Сопровождение/аутсорс — в районе 1,5/мес (опционально, ибо при правильно налаженной системе мониторинга ....).
итого: Мин 120, макс 220. Ежемесячное — 2к. сопоставимо с сегодняшней ценой за ГуглоДрайв? ну, на дистанции хотя бы в год? При том, что появляется масса плюсов — локальность. скорость доступа… Ну и опять же — рядом и свое.
Да, стойку и серверную я не считал. т.к. у нас ПТО этим занимается. И если их нету, то стоимость проекта конечно вырастит, но не смертельно.acyp
29.05.2018 04:56посмотрел цены на г.драйв. Ну да, 7 к.р/мес (84 к. по году). Срок окупаемости конечно великоват для сегодняшнего положения наверно.
Еще один вопрос тогда: а за активное использование диска Гугл ничего дополнительно не берет? Ведь это в итоге нагрузка на сеть…ReDisque Автор
29.05.2018 11:48ниже написал, чисто анлим получается 4 евро лицензия у Гугла.
acyp
29.05.2018 11:59Если 188 евро в месяц, то вариант со своим хранилищем отбивается примерно за 1,5 года даже в максимальной комплектации. Или я ошибаюсь?
ReDisque Автор
29.05.2018 12:04я думаю корректно считать не бу + поддержку надо добавлять, плюс зип
acyp
29.05.2018 12:30Тут же каждый по себе, по потребностям и по возможностям выбирает. У нас похожий бу-шный набор живет уже 5 лет без нареканий. Ставили себе на эксперимент, но прижилось и втянулось в компанейские процессы. Серверное бу живет достаточно долго.
Ну и история из жизни: на одной из конференций, в которых мне случилось участвовать были ребята из гугла. И они на «голубом глазу» рассказали, что в их дата-центрах используется кэжуал-оборудование. Ибо даже если рухнет, то можно быстро заменить. Прямо блочно, не разбираясь в поломке. Хард скотчем примотан, планки памяти воткнуты. Как-то так.
electronus
29.05.2018 06:32Так а сколько платите за 3Тб и 35 юзерей теперь?
ReDisque Автор
29.05.2018 11:408 евро за все, включая почту. Мы были на базовом тарифе с 30 Гб сначала, платили 4 евро, до анлима надо было добавить еще 4 евро, итого 8. Сейчас 47 лицензий за 376 евро, т.е. 188 евро в месяц за «добавку анлимную». А у Дропбокса было 165 долларов за 12 лицензий. Ну примерно 150 евро. Годовая экономия значительная.
electronus
29.05.2018 12:02+2За 188 в месяц я бы таки нашел способ сделать файлопомойку «дома».
Ещё резануло слух о локальных копиях больших размеров. Если бы была файлопомойка в офисе, да с гигабитом к ней, то никто бы не тянул бы к себе сотни мегабайт — работали бы по сети напрямую. Пожалейте своих дизайнеров.
Ваша схема хороша, если бы канал в Интернет был бы гигабитным, безлимитным и где-то в Северной Америке, поблизости к ЦОДу Гугла…
Massacre
29.05.2018 15:31По любому здесь можно очень много сэкономить, даже наняв удалённого сисадмина однократно для поднятия своего «облака» и периодически на поддержку (если потребуется)… И даже аренда сервера заметно дешевле выйдет, если религия не позволяет это делать локально!
tambovman
29.05.2018 11:42Непонятная история. Неорганизованные сотрудники, оставляющие аааааааа.psd, к делу не относится. Права? Скопируйте все и сделайте права как нужно. Как скопировать? Куча способов вроде. Наша компания (CloudEndure) позволяет миграцию в реальном времени. Так в чем пожар?
tambovman
29.05.2018 14:50Ну если вы сказали "точно", значит точно. Я просто против приемов "Секс, а теперь, когда мы привлекли ваше внимание..."
P.S. "поход" — это подход? :) Так это вы наоставляли аааааааа.psd? :)
irriss
30.05.2018 07:24Рассматривали возможность использовать Resilio Sync? Тот же dropbox/google drive только все у себя и под контролем
forcewake
Если у вас уже есть свои сервера, то почему бы не попробовать заиспользовать что-то вроде owncloud, nextcloud или что-то похожее?
ximik13
Причем это можно сделать и на арендованных виртуалках например при необходимости, А их конвертировать и переносить должно быть попроще, да и структура и доступ пользователей не сломается.
ReDisque Автор
Вы имеете в виду развернуть свое собственное облако? тут момент в том, что мы хоть и прокачаны в части IT но не настолько, чтобы обеспечивать качественную поддержку. Стараемся использовать проверенные решения на рынке. Но идея очень здравая, да.
forcewake
Собственно «развернуть свое собственное облако» звучит очень-очень громко. При условии что у вас есть хоть какая-то инфраструктура и она хоть как-то защищена (бэкапы, зеркалирование) — вся ваша активность сводится к уставновке и минимальной настройке.
Из плюсов — все при вас, нет необходимости бегать от одного cloud провайдера к другому, настройка как душе угодно и прочее.
Подумайте на досуге, возможно это сыкономит вам время и деньги в будущем.
selivanov_pavel
Как минимум надо грамотно настроить бекапы, протестировать их восстановление. Потом, если сервис торчит голым задом в интернет, надо его обновлять хотя бы при выпуске исправлений безопасности, которые надо мониторить. Обновления иногда могут ломать сервис, надо проверять. И так далее.
ИМХО подход у ребят совершенно правильный — то, что не является твоим основым продуктом, надо покупить как сервис и не парится.
sbh
сЭкономит
foxrus87
На самом деле для пользования тем же самым owncloud не требуется многих знаний и времени- установил, настроил и вперёд. Правда я им пользовался как временное хранилище (на работе облако так же под owncloud и там «живёт» порядка 1.2 Тб личных данных)… к чему это я, ах да- сейчас много мануалов, пошаговых инструкций почти для всего. Вы создаёте продукты, а я даже толком не знаю ни одного языка программирования, но смог установить и настроить :-) уж у Вас то всё выйдет на славу- это факт!