К сожалению, больше — не значит лучше. Безлимитный почтовые ящики в корпоративной почте — это рассадник беспорядка в корпоративном документообороте:
— Где договор с таким-то контрагентом?
— Он в почтовом ящике Иванова, который уволился два года назад — поищи у него по его миллиону писем.
Что у вас с резерным копированием почтовых ящиков? Если сотрудник уволится и удалит всю свою переписку, то за какой период сможете восстановить ее?
PostgreSQL используется по соображениям экономии? Делали вы сравнительные тестирования с microsoft sql? Также интересно было бы в двух словах о узнать резервном копировании и планах аварийного восстановления у вас (включая ситуации форс-мажора).
Я всё-таки предполагаю, что, если вы читаете статью про Azure, то базовыми терминами вы владеете.
Я точно также предполагаю, что если человек пишет статью про Azure, то базовыми терминами он владеет. И о я очень расстраиваюсь, когда выясняется, что человек не может объяснить что означают те или иные базовые вещи.
Я имел ввиду, что искать информацю по «Storage Account» удобне чем по «Учетой Записи Хранения» (не говоря уже о том, что «Учетная Запись Хранения» для моего уха звучит гораздо большим франкенштейном).
А я имел ввиду, что лучше, когда из статьи понятно что такое Storage Account и не приходится дополнительно гуглить, чтобы разобраться в вопросе.
Здесь проблема была в том, что русские названия многих компоненто очень сбивают с толку.
Они сбивают с толку, только если вы в них ничего не понимаете. Если бы вы в предмете разбирались, то статью можно было бы сделать куда более интересной. У вас же все свелось к перечислению услышанных от инженеров фактов.
Если человек захочет найти о чём шла речь, то ему комфортнее будет работать с оригинальными названиями.
То есть вы статьи пишете не для того, чтобы их читали, верно?
Некоторые текстовые франкенштейны меня удивляют:
облака в обозримом будущем полностью заменят on-premises инфраструктуру.
Почему «облака», а не cloud инфраструктура тогда уж? Ну или если пишите «облака», то заменяйте слово «on-premises инфраструктура» на «собственная инфраструктура» — это как-то проще и понятнее будет, не так ли?
Помимо слова «интерфейс», существует также тысячи других заимствованных слов как «джинсы», «шорты», «маркетинг», «импичмент», «футбол» и так далее. И я очень рад, что никому не приходит в голову писать тексты используя англоязычные аналоги этих слов: «я сегодня надел свои jeans, съел cheaps и пошел играть в football».
Для тех же слов, которые еще не стали заимствованными, или же для специализированных сокращений в научно-популярных статьях (коей является статья выше) желательно использовать или их русскоязычные аналоги или давать в тексте расшифровку. К примеру, в рамках данной статьи было бы приятнее увидеть нечто вида: «Вы не можете создать более 500 правил в одной группе безопасности сети (Network Security Group, далее — NSG)».
Когда же автор публикации во всю использует терминологию, не давая ее расшифровки, у меня лично складывается ощущение, что автор не разбирается в предмете публикации.
Названия продуктов не переводяться. А вот написать, что сокращение ARM — это Azure Resource Management, а не тип процессора стоило. Ну или обозначить, что входит в аббревиатуру NSG (чтобы было понятно, что это не какой-то вендор NSG, который что-то делает для азуры). Обозначенные мной в комментарии выше фразы также легко переводяться на русский язык и обратно без потери смысла.
«облака в обозримом будущем полностью заменят on-premises инфраструктуру»,
«Многие функции виртуальных машин в Azure завязаны на VM Extensions»,
«её главным достоинством — обширный Marketplace»,
«Когда вы разместите на одном Storage Account»
Неужели для этих слов нет не менее простых и понятных русскоязычных аналогов? Не говоря уже о том, что в правилах хорошего тона хотя бы один раз в статье расшифровывать краткие сокращения (ARM, NSG).
Спасибо за ваше разъяснение! В этом случае действительно логично ничего не удалять.
Думаю, что выигрыш от подобной дедупликации на практике огромный, но главное, что дропбокс еще может и приторговывать большими данными за счет такого подхода.
На самом деле, коректно выставить затронутый сервис мы можем только после того, как устраним инцидент. Процедура устранения инцидента выглядит следующим образом:
1) Регистрируем заявку со слов пользователя («В 1С ничего не работает!!!111ОдинОдинОдин111!!!!»)
2) Разбираемся что могло случиться у пользователя и локализуем причину инцидента.
3) Устраняем предполагаемую причину.
4) Связываемся с пользователем и уточняем, что теперь все работает.
5) Закрываем заявку, проставляем фактически затронутый сервис и в решении указываем причину инцидента и ее решение. В данном случае затронутым сервисом может быть сервис печати (при том что пользователь жаловался на 1С), а решение будет — «из-за зависания сервера печати пользователь не мог распечатать документ из 1С. Перезапустили сервер печати».
Точно также при закрытии заявки она может быть отнесена к инфраструктурным сервисам (рабочая станция, локальная сеть, сервера), если причиной послужили они.
Далее не только легко считать стоимость владения сервисом и его доступность, но и аргументированно вести диалог с руководством об общей адекватности пользователей и/или их технической подкованности и необходимости обучения.
«Почта не получается, из базы выбило, документы не открываются, не могу на принтере распечатать — я же говорю: ничего не работает!» — по какой услуге будете заводить заявку?
Я бы согласился, если бы у дропбокса был интенсивный уровень чтения/записи на гигабайт хранения, как, к примеру, у нетфликса. Но в реальности дропбокс — это файлопомойка и многие данные там просто лежат мертвым грузом. И какие бы дешевые диски не были, в случае файлопомоек ты быстро «вылетишь в трубу», если не будет управлять пространством.
Внедрение ITSM в компании нужно начинать не с определения каталога услуг, а с ответа на вопрос: «для чего нашей компании ITSM?». После честного ответа на этот вопрос все остальные вещи структурируются сами-собой.
Лично я использую ITSM для контроля двух аспектов работы ИТ-отдела:
1) Какой уровень сервиса получает компания от ИТ.
2) Сколько компания тратит на ИТ и куда уходят эти деньги.
По теме статьи:
1) ИТ-сервисы разделяются на пользовательские и на инфраструктурные. Естественно, пользовательские сервисы опираются на инфраструктурные и эта связь должна быть определена — она помогает при локализации инцидентов, а также нужна для расчета итоговой доступности пользовательских сервисов.
2) В случае сбоя инфраструктурного сервиса, достаточно завести заявку по инфраструктурному сервису. К этой заявке уже можно привязать все обращения пользователей. Нет никакого смысла насиловать свой хелпдеск необходимостью заводить 40 тикетов по каждому пользовательскому сервису из-за того, что в серверной отключили электроснабжение.
3) Стоимость владения нужно считать отдельно по инфраструктурным и пользовательским сервисам.
4) Доступность сервиса для пользователей не составляет труда вычислить зная доступности инфраструктурных сервисов и количество изолированных сбоев пользовательских сервисов, не связанных с инфраструктурными.
А пример привести вещей, которые невозможно зааутсорсить?
Невозможно заутсорсить стратегические планирование, работу над конкурентными преимуществами и контроль подрядчиков. Конечно, ничего не мешает передать и эти задачи внешним исполнителям, но качество исполнения упадет.
— Где договор с таким-то контрагентом?
— Он в почтовом ящике Иванова, который уволился два года назад — поищи у него по его миллиону писем.
Что у вас с резерным копированием почтовых ящиков? Если сотрудник уволится и удалит всю свою переписку, то за какой период сможете восстановить ее?
Да, было бы интересно об этом узнать. Спасибо!
Я точно также предполагаю, что если человек пишет статью про Azure, то базовыми терминами он владеет. И о я очень расстраиваюсь, когда выясняется, что человек не может объяснить что означают те или иные базовые вещи.
А я имел ввиду, что лучше, когда из статьи понятно что такое Storage Account и не приходится дополнительно гуглить, чтобы разобраться в вопросе.
Они сбивают с толку, только если вы в них ничего не понимаете. Если бы вы в предмете разбирались, то статью можно было бы сделать куда более интересной. У вас же все свелось к перечислению услышанных от инженеров фактов.
То есть вы статьи пишете не для того, чтобы их читали, верно?
Некоторые текстовые франкенштейны меня удивляют:
Почему «облака», а не cloud инфраструктура тогда уж? Ну или если пишите «облака», то заменяйте слово «on-premises инфраструктура» на «собственная инфраструктура» — это как-то проще и понятнее будет, не так ли?
Для тех же слов, которые еще не стали заимствованными, или же для специализированных сокращений в научно-популярных статьях (коей является статья выше) желательно использовать или их русскоязычные аналоги или давать в тексте расшифровку. К примеру, в рамках данной статьи было бы приятнее увидеть нечто вида: «Вы не можете создать более 500 правил в одной группе безопасности сети (Network Security Group, далее — NSG)».
Когда же автор публикации во всю использует терминологию, не давая ее расшифровки, у меня лично складывается ощущение, что автор не разбирается в предмете публикации.
Зачем использовать вот это все:
«облака в обозримом будущем полностью заменят on-premises инфраструктуру»,
«Многие функции виртуальных машин в Azure завязаны на VM Extensions»,
«её главным достоинством — обширный Marketplace»,
«Когда вы разместите на одном Storage Account»
Неужели для этих слов нет не менее простых и понятных русскоязычных аналогов? Не говоря уже о том, что в правилах хорошего тона хотя бы один раз в статье расшифровывать краткие сокращения (ARM, NSG).
Думаю, что выигрыш от подобной дедупликации на практике огромный, но главное, что дропбокс еще может и приторговывать большими данными за счет такого подхода.
1) Регистрируем заявку со слов пользователя («В 1С ничего не работает!!!111ОдинОдинОдин111!!!!»)
2) Разбираемся что могло случиться у пользователя и локализуем причину инцидента.
3) Устраняем предполагаемую причину.
4) Связываемся с пользователем и уточняем, что теперь все работает.
5) Закрываем заявку, проставляем фактически затронутый сервис и в решении указываем причину инцидента и ее решение. В данном случае затронутым сервисом может быть сервис печати (при том что пользователь жаловался на 1С), а решение будет — «из-за зависания сервера печати пользователь не мог распечатать документ из 1С. Перезапустили сервер печати».
Точно также при закрытии заявки она может быть отнесена к инфраструктурным сервисам (рабочая станция, локальная сеть, сервера), если причиной послужили они.
Далее не только легко считать стоимость владения сервисом и его доступность, но и аргументированно вести диалог с руководством об общей адекватности пользователей и/или их технической подкованности и необходимости обучения.
Давайте конкретный пример разберем:
Звонок пользователя: «у меня ничего не работает».
По какой услуге будете заводить заявку?
Все правильно, но 1 обращение = 1 заявка, а не 1 обращение = 30 заявок по всем затронутым сервисам.
Лично я использую ITSM для контроля двух аспектов работы ИТ-отдела:
1) Какой уровень сервиса получает компания от ИТ.
2) Сколько компания тратит на ИТ и куда уходят эти деньги.
По теме статьи:
1) ИТ-сервисы разделяются на пользовательские и на инфраструктурные. Естественно, пользовательские сервисы опираются на инфраструктурные и эта связь должна быть определена — она помогает при локализации инцидентов, а также нужна для расчета итоговой доступности пользовательских сервисов.
2) В случае сбоя инфраструктурного сервиса, достаточно завести заявку по инфраструктурному сервису. К этой заявке уже можно привязать все обращения пользователей. Нет никакого смысла насиловать свой хелпдеск необходимостью заводить 40 тикетов по каждому пользовательскому сервису из-за того, что в серверной отключили электроснабжение.
3) Стоимость владения нужно считать отдельно по инфраструктурным и пользовательским сервисам.
4) Доступность сервиса для пользователей не составляет труда вычислить зная доступности инфраструктурных сервисов и количество изолированных сбоев пользовательских сервисов, не связанных с инфраструктурными.
Невозможно заутсорсить стратегические планирование, работу над конкурентными преимуществами и контроль подрядчиков. Конечно, ничего не мешает передать и эти задачи внешним исполнителям, но качество исполнения упадет.