Тот случай, когда люди, настроившие один раз в жизни базу 1С, дают оценку специалистов, обслуживающих базу данных Toyota.
Для начала надо понимать, что такое «база данных Тойоты»: это сотни тысяч поставщиков по всему миру, миллионы номенклатур и партий, а также учет всех аспектов производственного процесса (чтобы всегда можно было ответить на вопрос, какой рабочий, в какое время и от какого поставщика закрутил гайку вот на этот автомобиль, как эта гайка попала на завод, каким маршрутом ехала и перемещалась по заводу и где все это время лежала). Прослеживаемость производственного процесса в Тойоте на самом высоком уровне, если не на самом высочайшем – это основа менеджмента качества. Естественно с этой базой работает не 10-20, а десятки тысяч человек одновременно.
Опустим аспекты технической реализации этой базы, которое, скорее всего, выходит далеко за рамки привычного вами «файла базы и лога транзакций» - обслуживают эту базу куда более компетентные ребята, чем мы с вами, иначе бы она просто не справлялась со своей нагрузкой.
Давайте представим, что мы потеряем данные из этой базы всего на 1 рабочую минуту. Чем это грозит? А тем, что придется остановить производство и проводить полную переинвентаризацию всех складов и всех производственных процессов, а иначе весь учет полетит в тар-тарары и ни о каком Дао Тойоты можно будет не говорить. Займет такая работа в рамках такого концерна далеко не пару дней.
Дак вот, у ребят случилась ошибка в базе, из-за которой база непрерывно росла. Скорее всего, разобраться с ошибкой на лету, а уж тем более обрезать базу просто так у них не было возможности. Поэтому да, они приняли непростое решение остановить все, чтобы запуститься через пару дней. Решение они приняли в целом в духе Тойоты – для них нормально остановить производство, чтобы разобраться в допущенной в рамках него ошибке.
Вы можете сколько угодно писать про бекапы и мониторинги, но если в базе возникла ошибка, ведущая к ее непомерному росту, то пока вы не выявите причину этой ошибки, все эти действия не имеют значения.
Ну если кредит брался только на покупку сервера, то бизнесу не проблема его вернуть. Если же кредит брался под основные производственные задачи, то покупка собственного сервера даже в кредит только улучшает финпоказатели — увеличивает размер основных средств, уменьшает кредиторскую задолженность. И наоборот, аренда основных средств (сервера, облачные сервисы) только ухудшает фин. показатели для кредиторов.
Кредит штука такая, для юриков в наших банков нет безотзывных кредитов, и когда настанут тяжёлые времена для компании банк — первым придёт за своими деньгами.
Ну да, в случае тяжелых времен кредиторы наложат штрафы за просрочку и платежи по кредиту приблизятся к платежам за аренды. Только вот в случае тяжелых времен при аренде поставщик услуг просто выключит сервер и привет.
У меня есть универсальный совет для финансовых директоров по переводу CAPEX в OPEX — возьмите кредит в банке. По сравнению с арендой в дата-центре вы получите сразу кучу плюсов:
1) Снижение платежей по OPEX в 3 раза (даже при кредите в 20% годовых) и при этом увеличение капитализации компании.
2) Отсутствие валютного риска, когда с очередным скачком курса доллара, стоимость аренды вдруг взлетает до небес.
3) Отсутствие рисков работы с внешним подрядчиком, для которого вы — никто.
Ну и да, не верьте никогда маркетологам, которые продают облачные сервисы — потому что они, по сути, продают вам те же самые сервера, но только в аренду и со своей маржой (даже так — МАРЖОЙ).
Очень корректное сравнение. Сама по себе методология ITIL не повышает производительность и скорость работы сервисных подразделений. Основной эффект от ITIL — это повышение прозрачности работы сервисных подразделений — сколько люди ждут в очередях, сколько занимает времени обработка запросов и так далее. А вот как эту прозрачность применять на благо — это уже вопрос к руководителю сервисного подразделения: нанимать больше людей (открывая дополнительные окна), упрощать или автоматизировать рабочие процедуры.
К примеру, мы видели в статистике 2015 года, что у нас много времени уходит на обработку запросов связанных с предоставлением прав доступа, поэтому мы напряглись и заскриптовали эту процедуру — теперь предоставление прав доступа — это пара кликов мышкой для применения соответствующего файла с правами доступа.
И как пользователь и как технический специалист могу сказать, что весь этот ITIL и в самом деле придумал, нет — «понавнедрял» на просторах нашей Родины только настоящий передаст. Техподдержки везде сплошь и рядом стали дубовыми. Аналогично и с обратной стороны: безумные и никому ненужные задания.
Ну я лично не имею ничего против электронных очередей во всяких госучреждениях и банках. Кое где внедрение самых основ ITIL серьезно меняет жизнь к лучшему.
Под термином «заявка» я подразумеваю любые обращения пользователя в техподдержку. Дальше они уже делятся в ServiceDesk на три категории — инциденты, запросы на обслуживание и консультации. В таблице 8 содержится статистика обращений по каждой из этих категорий. Каждая из этих категорий имеет свой SLA в ServiceDesk, но я в премии учитываю только общее количество выполненных заявок и сделаны они с нарушением SLA или нет.
А почему тогда этого показателя нет в системе мотивации?
Он есть в системе мотивации — раздел «Отзывы» в таблицах. Если ни по одной из заявок специалиста за месяц не было отзывов, то специалист получает коэффициент 0,6.
Как и времени выполнения заявки.
Время выполнения учитывается в разрезе «выполнено в срок или нет».
А «опросы удовлетворённости клиентов» в малом бизнесе будут работать?
Да, работают и очень даже хорошо. У нас после выполнения заявки пользователю приходит опрос с просьбой оценить качество работы специалиста по заявке (по 4 критериям) и пользователи активно в этих опросах участвуют — каждый месяц мы суммарно получаем порядка 60-80 заполненных анкет по заявкам. То есть примерно каждая четвертая заявка получает оценку от пользователя.
Ну, у всех сотрудников разная мотивация к работе, при этом она еще и меняется со временем — ребенок родился, квартиру ремонтирует, взял ипотеку и так далее.
Никакого противоречия с моей статьей нет. Масштабируемость — это возможность системы справляться с возрастающей нагрузкой исключительно за счет добавления аппаратных ресурсов. В моей статье описаны причины по которым в малом бизнесе масштабировать заложенную изначально инфраструктуру не получается и одна из таких причин (пункт 9 в статье) это как раз использование облачных сервисов.
Кажется, что перенос бизнес-логики, управляющей стриминговым сервисом такого масштаба — это все-таки существенный шаг (не на пару месяцев работы и объемы данных достаточно существенные могут быть):
Как мне кажется, основная причина переноса бизнес-логики в AWS — это сетевая задержка. Т.е. стримить потоковое видео вы можете из единственного дата-центра, но если вы будете авторизовать пользователей по всему миру в единственном дата-центре, то из-за сетевой задержки и особенности работы TCP (установление соединений и так далее) все задачи авторизации/поиска контента и так далее у пользователя будут «тормозить». Уверен, что как только бизнес-логика станет достаточно большой задачей, нетфликс все же соберется и организует свои собственные дата-центры по миру. Во-первых, это будет дешевле, ну а во-вторых, достаточно странно платить деньги за какие-то услуги своему прямому конкуренту (Amazon имеет свой собственный видео-сервис).
Все крупные проекты используют свое железо — облака выходят в 3-4 раза дороже, плюс облака — это инженеры и разработчики, на которых ты никак не можешь повлиять.
Ну и пока искал информацию по стартапам в облаках, нашел статью с кричащим названием: «WHY SOME STARTUPS SAY THE CLOUD IS A WASTE OF MONEY». www.wired.com/2013/08/memsql-and-amazon
Frenkiel estimates that, had the company stuck with Amazon, it would have spent about $900,000 over the next three years. But with physical servers, the cost will be closer to $200,000. «The hardware will pay for itself in about four months,» he says.
Общий вывод — если ваш стартап завтра может загнуться, то покупайте облака. Если планируете работать долго, то только свое железо, только хардкор.
Тот случай, когда люди, настроившие один раз в жизни базу 1С, дают оценку специалистов, обслуживающих базу данных Toyota.
Для начала надо понимать, что такое «база данных Тойоты»: это сотни тысяч поставщиков по всему миру, миллионы номенклатур и партий, а также учет всех аспектов производственного процесса (чтобы всегда можно было ответить на вопрос, какой рабочий, в какое время и от какого поставщика закрутил гайку вот на этот автомобиль, как эта гайка попала на завод, каким маршрутом ехала и перемещалась по заводу и где все это время лежала). Прослеживаемость производственного процесса в Тойоте на самом высоком уровне, если не на самом высочайшем – это основа менеджмента качества. Естественно с этой базой работает не 10-20, а десятки тысяч человек одновременно.
Опустим аспекты технической реализации этой базы, которое, скорее всего, выходит далеко за рамки привычного вами «файла базы и лога транзакций» - обслуживают эту базу куда более компетентные ребята, чем мы с вами, иначе бы она просто не справлялась со своей нагрузкой.
Давайте представим, что мы потеряем данные из этой базы всего на 1 рабочую минуту. Чем это грозит? А тем, что придется остановить производство и проводить полную переинвентаризацию всех складов и всех производственных процессов, а иначе весь учет полетит в тар-тарары и ни о каком Дао Тойоты можно будет не говорить. Займет такая работа в рамках такого концерна далеко не пару дней.
Дак вот, у ребят случилась ошибка в базе, из-за которой база непрерывно росла. Скорее всего, разобраться с ошибкой на лету, а уж тем более обрезать базу просто так у них не было возможности. Поэтому да, они приняли непростое решение остановить все, чтобы запуститься через пару дней. Решение они приняли в целом в духе Тойоты – для них нормально остановить производство, чтобы разобраться в допущенной в рамках него ошибке.
Вы можете сколько угодно писать про бекапы и мониторинги, но если в базе возникла ошибка, ведущая к ее непомерному росту, то пока вы не выявите причину этой ошибки, все эти действия не имеют значения.
Кстати, показательно что на hh.ru долгое время не было требований регулярной смены пароля, а в последние года два-три оно появилось.
1) Время реакции на ваш запрос;
2) Скорость выполнения вашей заявки;
3) Качество предоставленного решения;
4) Вежливость специалиста.
Ну да, в случае тяжелых времен кредиторы наложат штрафы за просрочку и платежи по кредиту приблизятся к платежам за аренды. Только вот в случае тяжелых времен при аренде поставщик услуг просто выключит сервер и привет.
1) Снижение платежей по OPEX в 3 раза (даже при кредите в 20% годовых) и при этом увеличение капитализации компании.
2) Отсутствие валютного риска, когда с очередным скачком курса доллара, стоимость аренды вдруг взлетает до небес.
3) Отсутствие рисков работы с внешним подрядчиком, для которого вы — никто.
Ну и да, не верьте никогда маркетологам, которые продают облачные сервисы — потому что они, по сути, продают вам те же самые сервера, но только в аренду и со своей маржой (даже так — МАРЖОЙ).
Очень корректное сравнение. Сама по себе методология ITIL не повышает производительность и скорость работы сервисных подразделений. Основной эффект от ITIL — это повышение прозрачности работы сервисных подразделений — сколько люди ждут в очередях, сколько занимает времени обработка запросов и так далее. А вот как эту прозрачность применять на благо — это уже вопрос к руководителю сервисного подразделения: нанимать больше людей (открывая дополнительные окна), упрощать или автоматизировать рабочие процедуры.
К примеру, мы видели в статистике 2015 года, что у нас много времени уходит на обработку запросов связанных с предоставлением прав доступа, поэтому мы напряглись и заскриптовали эту процедуру — теперь предоставление прав доступа — это пара кликов мышкой для применения соответствующего файла с правами доступа.
Ну я лично не имею ничего против электронных очередей во всяких госучреждениях и банках. Кое где внедрение самых основ ITIL серьезно меняет жизнь к лучшему.
Он есть в системе мотивации — раздел «Отзывы» в таблицах. Если ни по одной из заявок специалиста за месяц не было отзывов, то специалист получает коэффициент 0,6.
Время выполнения учитывается в разрезе «выполнено в срок или нет».
Да, работают и очень даже хорошо. У нас после выполнения заявки пользователю приходит опрос с просьбой оценить качество работы специалиста по заявке (по 4 критериям) и пользователи активно в этих опросах участвуют — каждый месяц мы суммарно получаем порядка 60-80 заполненных анкет по заявкам. То есть примерно каждая четвертая заявка получает оценку от пользователя.
Как мне кажется, основная причина переноса бизнес-логики в AWS — это сетевая задержка. Т.е. стримить потоковое видео вы можете из единственного дата-центра, но если вы будете авторизовать пользователей по всему миру в единственном дата-центре, то из-за сетевой задержки и особенности работы TCP (установление соединений и так далее) все задачи авторизации/поиска контента и так далее у пользователя будут «тормозить». Уверен, что как только бизнес-логика станет достаточно большой задачей, нетфликс все же соберется и организует свои собственные дата-центры по миру. Во-первых, это будет дешевле, ну а во-вторых, достаточно странно платить деньги за какие-то услуги своему прямому конкуренту (Amazon имеет свой собственный видео-сервис).
www.datacenterdynamics.com/content-tracks/design-build/microsoft-sells-data-center-to-uber/94260.fullarticle
Ну и пока искал информацию по стартапам в облаках, нашел статью с кричащим названием: «WHY SOME STARTUPS SAY THE CLOUD IS A WASTE OF MONEY».
www.wired.com/2013/08/memsql-and-amazon
Общий вывод — если ваш стартап завтра может загнуться, то покупайте облака. Если планируете работать долго, то только свое железо, только хардкор.