Comments 34
Хорошая статья.
Вроде бы — азы, давно известные истины… Но не много знаю компаний, где все это систематизировано и учтено.
Может, даже ближе к «Информационной безопасности», а не к PM.
Вроде бы — азы, давно известные истины… Но не много знаю компаний, где все это систематизировано и учтено.
Может, даже ближе к «Информационной безопасности», а не к PM.
Поделились мыслями — спасибо, но мало. Кому пишите?
Если для начинающесь продукт оунеров — то они остановятся на SMS. Для такой аудитории надо расписать конкретику — где брать рекомендованных админов для постоянного пригляда, каким способом отзеркалировать сервера в другой ДЦ или как быстро их поднять из бекапа.
Если для опытных овнеров — то они это и так в голове держат, а хочется посмотреть рабочий документ/докладную записку из вашей компании типа «План реализации мероприятий по обеспечению безотказному функционированию вербсервисов (редакция 3.Х, исправленная)», где раскрыты критерии отказоустойчивости, административные и технические мероприятия, расписанияучений регулярных проверок. Как-то так.
Если для начинающесь продукт оунеров — то они остановятся на SMS. Для такой аудитории надо расписать конкретику — где брать рекомендованных админов для постоянного пригляда, каким способом отзеркалировать сервера в другой ДЦ или как быстро их поднять из бекапа.
Если для опытных овнеров — то они это и так в голове держат, а хочется посмотреть рабочий документ/докладную записку из вашей компании типа «План реализации мероприятий по обеспечению безотказному функционированию вербсервисов (редакция 3.Х, исправленная)», где раскрыты критерии отказоустойчивости, административные и технические мероприятия, расписания
Спасибо. Интересно. Взял на заметку. А зачем настраивать софт, достаточно установить на сайт яндекс метрику.
Дочитал до SMS, а потом стало скучно… Автор! Больше экшена и конкретики! И какого фига вы пишете такую ерунду, как «На mail.ru, правда с ограничениями, можно отправлять смс-ки c вашего почтового ящика беспатно, но не чаще раз в полчаса.»???? Как ваш замечательный nagios отправит SMS'ку, если тупо пропадет доступ в интернет? Раньше было сложнее — если хотелось бюджетное решение, то нужно было подключать мобильники и т.п. А сейчас же USB-модемы стоят копейки — хоть оботправляйся этих SMS'ок…
Ну это же проще смс-ки отправлять нагиосом через веб-шлюз — одна строка в конфиге. Согласен, напрямую USB-модемом — надежнее, но нужно уметь мобильники к юниксу подключать :-)
[удивленно] Мы за простоту или за надежность говорим?
Насчет «нужно уметь» — давайте разделять мух и котлеты: уметь нужно администратору — ему за это деньги платят, — а если не умеет (что тоже нормально), то пусть учится. А именно owner'у нужно знать, что это возможно и требовать этого с администраторов (вроде как именно об этом пост?), чтобы не было как в комменте чуть выше — админу сказали «Обеспечь уведомление по SMS!», а админ поставил Яндекс.Метрику на сайт и думает, что он теперь весь из себя такой замечательный и «обеспечил» — это же несерьезно…
Насчет «нужно уметь» — давайте разделять мух и котлеты: уметь нужно администратору — ему за это деньги платят, — а если не умеет (что тоже нормально), то пусть учится. А именно owner'у нужно знать, что это возможно и требовать этого с администраторов (вроде как именно об этом пост?), чтобы не было как в комменте чуть выше — админу сказали «Обеспечь уведомление по SMS!», а админ поставил Яндекс.Метрику на сайт и думает, что он теперь весь из себя такой замечательный и «обеспечил» — это же несерьезно…
>успели даже обсудить «висение» в твиттере…
>Клиенты пишут/звонят вам и коллегам, в т.ч. в твиттер компании
Как же шагнул прогресс за последние годы…
>Клиенты пишут/звонят вам и коллегам, в т.ч. в твиттер компании
Как же шагнул прогресс за последние годы…
> «боевые» сервера
удобнее называть это production-серверами
удобнее называть это production-серверами
Именно поэтому Господь изобрёл хостеров. Здравствуйте статья из конца XX-го века.
У большинства хостеров — один датацентр :-) А это — уже не XXI век, посмотрите на архитектуру, к примеру, амазона.
Чо, круто амазону. Не вижу ничего такого в одном или нескольких датацентрах. То что приписывают Амазону — безотказность — у них тоже не очень и не всегда. При том что «один датацентр» в общем случае достаточно редко падает, баланс между вот этим всем что написано, стоимостью и потерями от технических простоев в исключительных случаях — всё это явно не в пользу Амазона. Опять же в общем случае.
Автор, все прекрасно знают, что существует огромное количество программ автоматизированного мониторинга. Нужно было привести конкретные примеры, ваш пост было читать, прямо скажем, неинтересно.
Много лирики. Мало конкретики. Но общий принцип, я думаю многим нелохо почитать и такой
В целом, да, интересно. Но слишком много теории. Хочется примеров
Может будет продолжение? :)
Может будет продолжение? :)
Я бы добавил:
- автоматический мониторинг должен быть, по-хорошему, распределенным — «другая» площадка на которой он запущен так же ненадежна, как площадка основного проекта. А если мониторинг «лежит», то он не нужен;
- днс должны быть правильно настроены и расположены — к сожалению, это не для всех сисадминов очевидно. Нельзя располагать все днс внутри одной сети (тем более, внутри локальной сети компании, которая по определению менее надежна, чем средненький хостинг). Чтобы изменить адрес сервера надо иметь свой днс и менять именно записи, а не адреса ДНС в настройках домена у регистратора. В первом случае изменения почти мгновенные, во втором — до 6 часов.
Мне всегда было интересно: что побуждает некоторых писать «Клиент» и «Пользователь» с большой буквы? Это же вроде бы норма только для юридических документов («… именуемый в дальнейшем "Клиент"...»); в обычных текстах это смотрится довольно дико и сильно режет глаз. Или это требование корпоративного стандарта?
Это признак уважения к ним :-)
Больше похоже на попытку подлизаться:) Да и не по правилам языка это.
А начать следовало бы с уважения к коллегам: так и вижу картину как иванушка-дурачёк«начинающий productowner» прочтёт этот опус и начнёт что-то такое «выжимать максимум» и «воспитывать» тех.дира и всех подряд «толкать в зад». Только сотрудничество и только уважение.
Повышение доступности стоит денег. Зачастую немалых.Чем ближе мы приближаемся к 1 тем дороже каждый шаг. Если у компании есть ресурсы пойти по этому пути и есть потребность — так надо разработать план, выделить ресурсы и реализовывать его. Ну а если нет — то так и не надо заниматься ИБД.
Повышение доступности стоит денег. Зачастую немалых.Чем ближе мы приближаемся к 1 тем дороже каждый шаг. Если у компании есть ресурсы пойти по этому пути и есть потребность — так надо разработать план, выделить ресурсы и реализовывать его. Ну а если нет — то так и не надо заниматься ИБД.
Я так понимаю, эта статья «Основы системного администрирования для Product Owner'ов»?
Очень понравилось, спасибо!
Sign up to leave a comment.
Доступность веб-проектов — спокойной ночи, ProductOwner