Комментарии по теме

«Что делать, если надо внедрять?»
Олег Точенюк:
Как-то вот читал, читал, и вроде тема интересная и комментариев что-то нет, а потом понял или точнее не понял, но предположу почему в ответ тишина, а потому что никто наверное так и не понял как же...
«Ра­сши­ре­нная настройка за­клю­чи­те­льной проводки в Регистре Ма­те­ри­а­лов»
Виктор Гришин:
Спасибо :) Пользу этой статьи трудно переоценить. Особенно диаграмма с видами операций. Помогает быстро разобраться. Данная статья очень помогла мне в трудную минуту.

База знаний

Вы можете подписаться на эту колонки этого автора, если авторизируетесь или зарегистрируетесь

Тонкости перевода, или как потерпеть неудачу в проекте из-за одного слова?

04 августа 2012, 19:39

Тонкости перевода, или как потерпеть неудачу в проекте из-за одного слова?

При выборе инфраструктурного решения очень часто упоминается такой нефункциональный показатель, как доступность системы. Более того, в подавляющей большинстве случаев говорится не просто о доступности, а о высокой доступности. Почему доступность должна быть «высокой»? Что скрывается за этим понятием? Почему нужно стремиться к достижению высокой доступности системы? Как оценить уровень доступности системы на практике? Вопросов, возникающих при ассоциации со словосочетанием «высокая доступность», огромное количество, и в следующих статьях будут приведены основные термины и определения, а также наглядно продемонстрированы методики расчета доступности системы  для практического применения. 

Ситуация осложняется тем, что есть еще понятие «готовности» системы, а что же тогда оно означает? Надо отметить, что очень часто происходит смешивание понятий: разницу между доступностью и надежностью можно хотя бы интуитивно почувствовать, ведь существует понятие RAS-характеристик (reliability, availability, serviceability) – если  в английской терминологии существует два понятия, значит надежность (reliability) и доступность (availability) чем-то различаются. А вот разницу между доступностью и готовностью понять сложнее.

В реальности происходит некое смешение понятий, и зачастую под “availability” понимается именно доступность системы, но на самом деле это не так. Доступность является наиболее привычным среди вариантов перевода термина «availability», но надо понимать, что большинство словарей являются достаточно общими и предназначены для использования в различных отраслях. Термин «доступность» будет соответствовать «availability» если речь идет о доступности каких-либо товаров на складе, доступности продуктов в магазине на полке. Нас же интересует значение этого слова как профессионального термина из области ИТ. Поэтому при использовании понятия «availability» с точки зрения ИТ более правильным будет перевод термина как «готовность». Попробуем это обосновать.

Мы видим, что в интернет-источниках на русском языке очень часто все три понятия (готовность, доступность и надежность) перемешиваются, например встречаются следующие словосочетания:

В представленных выше примерах понятия готовности и доступности являются взаимозаменяемыми, надежность и готовность обозначает одно и то же и т.п. – это кардинально неверно. И вот почему мы можем так утверждать:

В ГОСТ Р ИСО/МЭК 20000-1-2010 термин «availability» трактуется, как ни удивительно, именно как доступность системы, обозначая способность компонента или услуги выполнять требуемые функции в определенный момент или в течение заданного интервала времени. Также в ГОСТ приводится примечание:

«Доступность обычно выражается как отношение интервала времени, в течение которого услуга является фактически доступной для реализации, к установленному соглашением периоду предоставления услуги»

Википедия также предоставляет перевод термина «availability» как доступность, подразумевая под этим свойство информационных ресурсов, в том числе информации, определяющее возможность их получения и использования по требованию уполномоченных лиц. 

Здесь отметим следующее: важно отличать один стандарт от другого. Например, в статье про «availability» на Википедии речь идет об информационной безопасности. Если же мы пытаемся сформулировать определения для аппаратного обеспечения, то необходимо использовать другие стандарты или ГОСТ, поскольку нас интересует значение, имеющее «легальный» статус. Википедия же, будучи несомненно важным источником информации, является лишь отражением мнений отдельных лиц или групп лиц (редакторов и авторов), но не «легальным» документом.

В ГОСТ Р 53480-2009 «Надежность в технике. Термины и определения» «availability» переводится как готовность, обозначая способность изделия выполнить требуемую функцию при данных условиях в предположении, что необходимые внешние ресурсы обеспечены

Очень важны примечания:

  1. Эта способность зависит от сочетания свойств безотказности, ремонтопригодности и поддержки технического обслуживания
  2. «Данные условия» могут включать климатические, технические или экономические обстоятельства
  3. Необходимые внешние ресурсы, кроме ресурсов технического обслуживания не влияют на свойство готовности. 

Под внешними ресурсами понимается, например, электричество, ведь если сервер обесточен, то он определению не может быть готов к использованию. 

Надо отметить, что именно в последнем ГОСТ приводится наиболее точное и правильное определение по отношению к ИТ-инфраструктуре. Понятию «доступность» в английском языке соответствует термин «accessibility», который относится больше к уровню программного обеспечения. Данный термин описывается в стандартах ISO/IEC 24756 и ISO 9241. 

Итак, мы видим, что «готовность» и «доступность» на самом деле не только часто выступают на практике как взаимозаменяющие или дополняющие друг друга термины, но и, скорее всего, являются двойным переводом одного и того же термина «availability» с английского языка.

Теперь рассмотрим более привычную всем тему: отличие готовности системы (availability) от надежности. 

Согласно ГОСТ Р 53480-2009 надёжность – свойство готовности и влияющие на него свойства безотказности и ремонтопригодности, и поддержка технического обслуживания. 

Очень важный момент, что в английском языке понятию «надежность» может соответствовать термин «dependability», а вовсе не «reliability», как многие привыкли полагать.

Последнее в русском языке означает «безотказность» и согласно ГОСТ Р 53480-2009 является способностью изделия выполнить требуемую функцию в заданном интервале времени при данных условиях. 

С другой стороны, в ГОСТ 34.003-90 «reliability» переводится именно как «надежность» и обозначает комплексное свойство АС сохранять во времени в установленных пределах значения всех параметров, характеризующих способность АС выполнять свои функции в заданных режимах и условиях эксплуатации. Также в данном ГОСТ прописано, что надежность АС включает свойства безотказности и ремонтопригодности АС, а в некоторых случаях и долговечности технических средств АС.

Получается, что при разговоре о нефункциональных требованиях к системе и обсуждении RAS-характеристик речь идет все же о безотказности оборудования. В случае если мы говорим о надежности, то тогда нужно еще учитывать, как минимум, ремонтопригодность и долговечность. 

Очень часто возникает вопрос, достаточно ли иметь хорошие показатели решения по надежности или обеспечить только высокую готовность системы?

Ниже представлена диаграмма, на которой цифрами указаны различные варианты комбинаций нефункциональных характеристик систем:

  • 1 – Решение обладает высокой надежностью, но имеет слабые показатели готовности
  • 2 – Решение обладает высокими показателями надежности и готовности
  • 3 – Решение обладает высокой готовностью, но имеет слабые показатели надежности
  • 4 – Решение обладает низкими показателями надежности и готовности

 

Рассмотрим поочередно каждую из комбинаций:

Случай 1: что означает вариант, когда решение высоконадежно, но не обладает высокими показателями по готовности? Действительно ли нужно обеспечивать высокую готовность решения? Для доказательства того, что для построения системы корпоративного уровня недостаточно обеспечения высоких показателей только по надежности, приведем следующий пример: если решение обладает высокими показателями по надежности, это означает, что система будет функционировать без сбоев, но абсолютно не гарантированно, что к ней будет доступ со стороны внешних систем. Также это может означать, что аппаратные средства формально готовы к эксплуатации, а, например, база данных еще не стартовала, что отражает неготовность системы к работе. В целом, использование системы в случае 1 крайне не рекомендовано. 

Случай 2. Решение обладает высокими показателями как по надежности, так и по готовности. Это означает, что доступ осуществляется по требованию без прерываний в работе. Этот случай является целевым при построении систем корпоративного класса. 

Случай 3. Рассмотрим случай, когда система обладает свойством высокой готовности, но не является надежной.  В этом случае при работе с рассматриваемой системой возможны перерывы в работе по причине сбоя оборудования, вызванные неполадками в аппаратном обеспечении. Также можно отметить, что при сбоях в работе аппаратных средств система не будет обладать свойствами высокой готовности ввиду отказов в работе памяти, дисков, процессоров. 

Случай 4. Решение обладает низкими показателями как по надежности, так и по готовности. Это означает, что в работе оборудование могут возникать сбои, причем непрогнозируемые. В свою очередь это приводит к долгим простоям в связи, например, с необходимостью корректного запуска базы данных или прикладных систем. Можно однозначно утверждать, что при создании решения корпоративного уровня с жесткими требованиями по качеству предоставляемого сервиса данный случай рассматривать не рекомендуется. 

Почему же стоит обращать столь пристальное внимание на трактовку терминов? В этом случае большинство заказчиков говорит, что это лишь тонкости перевода и не обращают на это внимания. Однако эта, казалось бы, несущественная разница может привести к весьма неприятным последствиям, ведь одно дело строить надежную систему, другое – готовую и третье - доступную.

К чему может привести неправильный выбор соотношения готовности, доступности и надежности?

  • Утраченный «темп», то есть потерянное время на исправление ошибок, а, значит и утраченные инвестиции
  • Утраченные данные, важные для бизнеса
  • Моральный и денежный ущерб, потеря клиентов (в случаях, когда системы конкурентов позволяют им поддерживать бизнес, а ваши системы бизнес остановили. Типичный пример – падения мобильных операторов в случаях перегрузки в канун Нового Года и другие праздники). 

Схематично все указанные характеристики можно представить в виде следующей иерархии:

Суть иерархии заключается в следующем: система не может быть готовой, если она ненадежна; система не может быть доступна, если она не готова. Если соотносить данную схему с аппаратным и программным обеспечением, то, как правило, понятие надежности относится к аппаратной части, готовность относят ко всей системе в целом (аппаратная часть + уровень операционной системы + софт). Если надежность и готовность оценивают именно саму систему, то при определении доступности необходимо уже брать в расчет внешние факторы, например каналы связи между пользователем и сервером, т.е. оценивать систему извне. 

Получается, что если в требованиях к системе прописаны характеристики по доступности, то это может означать абсолютно разные денежные вложения по сравнению с выполнением требований по высокой готовности. Это связано, как уже упоминалось, с необходимостью модернизации каналов связи, которые не включаются в оценку при создании систем высокой готовности. 

Итоговая таблица соответствия понятий выглядит следующим образом:

Поэтому, в первую очередь, перед формулированием требований к системе необходимо убедиться, что все участники проекта правильно трактуют понятия, которые будут использоваться в дальнейшем. И не просто по причине того, что так принято делать, а по причине абсолютно различных финансовых вложений в проект в зависимости от использования того или иного термина.

В следующей статье будет более подробно рассмотрен расчет готовности системы, а также наглядно продемонстрированы причины повышения уровня готовности решений. 

Ролевое назначение : Руководитель / Manager, SAP Консультант / Consultant

Функциональная область : Информационные технологии / IT, Basis, ABAP

Ключевые слова : IBM

Комментарии:

Олег Точенюк (Рейтинг: 10843) 00:10, 07 августа 2012

"Тонкости перевода, или как потерпеть неудачу в проекте из-за одного слова" - Я так понял это теоретическое утверждение? Т.е. практических примеров, что такое где-то, у кого-то произошло я не услышу? Ну тогда заголовок, как-то не отражает смысла ниже написанного. Я бы тогда дожал и написал бы так "как потерпеть неудачу в проекте из-за одного не правильно поставленного знака препинания" и привести в эпиграфе всем известный пример фразы: "казнить нельзя помиловать", знак запятой или точки, пользователи могут поставить по желанию сами :-)