На мой взгляд, в статье путаница в понятиях “плохой” и “неопытный”, а ведь порой это совершенно разные вещи. Неопытный сотрудник может делать работу хорошо пусть даже и долго, и хороший специалист может по каким-то субъективным причинам делать работу плохо.
Чтоб проиллюстрировать разницу, можно рассмотреть простой пример работы автослесаря, перед которым стоит задача закрутить гайку.
Плохой неопытный слесарь: возьмёт гайку, будет полчаса вертеть её в руках, а потом закрутит руками и дожмёт плоскогубцами, при этом сорвав грани гайки. Итог: работу делает долго и неправильно.
Хороший неопытный слесарь: возьмёт гайку, потратит минут двадцать на прочтение инструкции по закручиванию гаек, затем еще пять минут на поиск подходящего ключа, затем пять минут будет крутить гайку. Итог: работу делает долго, но правильно, если в чём-то ошибается, то делает выводы и в следующий раз уже не косячит, со временем набирается опыта и увеличивает темпы.
Хороший опытный слесарь: на глаз определит размер гайки, за минуту подберёт ключ, затем еще минуту потратит на закручивание. Итог: работу делает быстро и правильно, если нужно, то напишет документацию по закручиванию гаек, а также без проблем научит неопытных.
Плохой опытный слесарь: а нахрена эту гайку закручивать – забью молотком, тысячу раз так делал, и всё всегда было ок. Итог: работу делает быстро, но неправильно.
Еще обязательно нужно помимо всего вышеобозначенного установить на сайт чат техподдержки (типа jivo). Не беда, что оператор 23 часа в сутки оффлайн, зато пользователь будет доволен, что про него не забыли :)
Так и у айтишника хватает в жизни опасностей, вытекающих из-за особенностей труда:
— Постоянный недосып (не секрет, что многие работают по 10-12 часов в сутки) может сказаться на притуплении внимания в конце рабочего дня и стать причиной к примеру автокатастрофы с летальным исходом.
— Постоянные стрессы (вызванные вечной гонкой, дедлайнами и т.п.) ведут к сердечным заболеваниям ближе к старости и как следствие к ранней смерти.
— Сидячий образ жизни ведёт к болям в спине и геморрою (не смертельно, но может сильно подпортить жизнь).
— Повышенная нагрузка на глаза (к счастью, ослепших айтишников пока ещё не видел, а вот очкариков знаю достаточно много).
Я ушёл из Google ещё в 2012 году и основал свой стартап. Конечно, свою роль сыграли престиж и желание заниматься любимым делом, но главная причина — деньги. Я мечтал разбогатеть и никогда больше не работать.
Вспомнился старый анекдот, услышанный когда-то в Черногории...
Приезжает в Черногорию американец. И каждый день видит с балкона своей виллы одно и то же: мужик сидит на берегу моря с хлипкой удочкой. Поймает за день пару рыбешек и довольный идет домой.
Американец не выдерживает и подходит к рыбаку:
— Слушай, парень, а почему бы тебе не купить удочку получше?
— Зачем?
— Ну как? Поймаешь больше рыбы, начнешь ее продавать.
— Зачем?
— Заработаешь денег и откроешь лавку.
— И что?
— Как что? Капитал появится, сможешь лодку купить. Наловишь в сто раз больше, чем сейчас…
— И что?
— Разбогатеешь и сможешь наконец никогда больше не работать…
Местный смотрит на него, как на придурка, и говорит: Ты что, не видишь? Я и так не работаю!
Очень красиво заминусовали ВОПРОС!!!
А вам не кажется, что минусовать вопрос глупо, при этом даже не приведя ссылки на какой-нибудь мануал в пользу других решений хотя бы с минимальным анализом затраченных ресурсов (как железных, так и временных на разворачивание)?
Разве конфигурирование этой связки сравнится с элегантностью решения, которое предоставляет Docker: одна консольная команда в Docker — run (ну или 3 что у меня) против N команд связки lxc+ansible?
Идея нелепа только если смотреть не дальше деревянной коробки.
По мне так автор сделал прекрасный «Hello, world», который можно положить в основу для создания умного дома — т.е. управления фактически всеми электрическими устройствами с мобильного телефона!
некоторые специально отключают предупреждение о невыпущенных закрылках, потому что оно часто ложно срабатывает на рулении и очень раздражает
В системах мониторинга ИТ-проектов проблема игнорирования встречается не редко. И порой она связана не только с ложными срабатываниями, но и неправильным выбором настроек системы мониторинга.
Схема простая:
1. Руководитель предлагает: а давайте отслеживать такой-то параметр системы (в данном примере он не является критическим).
2. Админ аккуратно настраивает сбор данных по обозначенному параметру. На данном этапе все довольны: система собирает информацию, которая аккуратно складируется в базу данных и никого не отвлекает.
3. Но в какой-то момент руководитель вдруг решает, что админу неплохо было бы получать уведомления, если отслеживаемый параметр превысит определённое значение, и по каждому случаю срабатывания проводить расследование.
4. Админ настраивает уведомления. Но вот беда, уведомления приходят по 10 раз в сутки, причём не только в рабочее время на панель мониторинга, но и во время отдыха на телефон (не все компании могут позволить круглосуточное дежурство).
5. Через несколько дней админ просто выключает телефон перед сном, игнорируя не только уведомления по параметру п.1, но и все остальные.
Чтоб подобного не случалось, нужно ещё на этапе проектирования системы мониторинга все параметры разбить на группы:
1. Незначительные — информация собирается, но никак не проявляется. В Zabbix это обычный элемент данных (Item) без триггера (Trigger). Данная группа параметров никак не влияет на работу системы и может использоваться для получения дополнительных сведений (например, при расследовании падений или оптимизации).
2. Информационные — информация собирается и отображается в панели мониторинга. На примере Zabbix: элемент данных + триггер, но без действия (Action). Данные параметры не приведут к моментальному краху системы, но важны для прогнозирования и предотвращения падений в будущем.
3. Критические — информация собирается, факты превышения пороговых значений сразу же отображаются в панели мониторинга, а админу отправляется уведомление. В Zabbix: элемент данных + триггер + действие. Только при приближении к критической ситуации нужно дёргать админа в нерабочее время, и только так можно добиться, чтоб он даже не задумывался об игнорировании уведомлений.
Неудачный копипаст? В 4 утра спать надо, а не комментарии писать :-)
:)
Насколько корректно экстраполировать результаты этого теста на услугу «виртуальный хостинг», которая обеспечивается мощным сервером, на котором «пасется» несколько десятков пользователей с несколькими сотнями сайтом?
Как-то мне приходилось работать админом в компании, занимающейся хостингом. В большинстве случаев, количество сайтов на сервер колебалось от 20 до 100. А вот совокупная нагрузка как раз таки была не очень большой и колебалась в пределах 0...10 запросов в секунду (в зависимости от времени суток), что в принципе и логично: серьёзные высоконагруженные проекты обычно на виртуальном хостинге не размещают.
в случае с каким-нибудь php, тормоза приведут либо к тому, что страничка у клиента будет грузиться сильно дольше обычного (что приведет к тому, что клиент закроет страницу и уйдет к конкурентам), либо к тому, что тот же php-бекенд будет очень долго рендерить, что приведет к 503 или аналогичной ошибке (опять же клиент потерян).
Специально для вас сделал простое нагрузочное тестирование тестового виртуального сервера: 1 CPU / 1Gb Ram / 4 Gb swap SSD. Характеристики выбрал, чтоб максимально переложить нагрузку на своп. На сервере Ubuntu 18 LTS, Nginx, Php7.2-fpm, Mysql, в качестве приложения сайт на Wordpress с 50 страницами.
2. Запускаем простой скрипт, чтоб забить память и уйти в своп:
i=0; while true; do a[${i}]=100000000000000000000000000000; i=$(($i+1)); done
Ждём, чтоб оперативка полностью забилась (к примеру, можно отследить в другом терминале через htop) и останавливаем скрипт Crtl+Z (скрипт нужно именно остановить, а не убить посредством Ctrl+C, чтоб данные остались в памяти).
Теоретически, система им должна выделить память в свопе.
4. Открываем локально 5 терминалов и в случайном порядке запрашиваем страницы в бесконечном цикле:
while true; do curl http://hostname/?p=$(echo $((RANDOM%50)) ); sleep 1; done
Как результат мы создали нагрузку примерно 5 запросов в секунду. Да, сервер тормозит, что в принципе логично. Но задержка не 30 секунд (необходимо для ошибки 503 при дефолтном max_execution_time), а всего 1-3 секунды. Как я и писал выше: да, сервер тормозит, но отвечает. Из-за пары секунд ожидания на интервале 5-10 минут (пока админ фиксит проблему) клиент точно не уйдет к конкурентам. А вот если в браузере ошибка 502, то у него не будет никаких оснований чего-то ждать.
Я и НЕ ПИСАЛ, что использование свопа для штатных задач — это круто. Но своп позволяет избежать краха системы, если что-то пошло не так, и какой-нибудь процесс сожрал слишком много памяти. Своп — это как буфер, использование которого даёт админу запас времени, чтоб решить проблему.
Дальше система будет попросту тормозить и скидывать странички на диск.
Да, система будет тормозить, НО РАБОТАТЬ! Думаю, многие со мной согласятся, что это гораздо лучше для репутации, чем ошибки в браузерах клиентов.
Далее, настраиваете метрику для Заббикс, которая будет сообщать админу, что сервер залез в своп. А уже админ руками убъёт (или перезапустит) жадный процесс.
После этого останется всего лишь выполнить 2 команды, которые пренесут оставшиеся в свопе данные в оперативку:
Администраторы сразу же определили причину – нехватка оперативной памяти. В логах легко было увидеть случаи OOM, когда на сервере кончалась память и ядро убивало nginx.
shanlove, действительно, фигню я написал, приношу извинения (от меня вам +). У заказчика был специальный тариф в Azure, с хорошими скидками, вот и получалось гораздо дешевле. Но если считать по обычным тарифам, то цены примерно одинаковые.
Основной недостаток AWS по сравнению с Azure — это платный исходящий трафик. В моей практике было несколько проектов, где мы вынуждены были отказаться от AWS в пользу Azure с целью сокращения издержек.
YourChief, спасибо за дополнения и хорошую критику.
Ну это тоже не догма. Модель TOFU (trust on first use) — действительно слабое место всех систем, которые ещё ни разу не обменивались ключами. Однако этого можно (и нужно) избегать. Есть целый ряд механизмов:
Ручное или полуручное наполнение known_hosts со сверкой отпечатка.
Имеете ввиду отправлять открытый ключ или его отпечаток через другой канал связи (почта, месенджер и т.п.)?
Чтоб проиллюстрировать разницу, можно рассмотреть простой пример работы автослесаря, перед которым стоит задача закрутить гайку.
Плохой неопытный слесарь: возьмёт гайку, будет полчаса вертеть её в руках, а потом закрутит руками и дожмёт плоскогубцами, при этом сорвав грани гайки. Итог: работу делает долго и неправильно.
Хороший неопытный слесарь: возьмёт гайку, потратит минут двадцать на прочтение инструкции по закручиванию гаек, затем еще пять минут на поиск подходящего ключа, затем пять минут будет крутить гайку. Итог: работу делает долго, но правильно, если в чём-то ошибается, то делает выводы и в следующий раз уже не косячит, со временем набирается опыта и увеличивает темпы.
Хороший опытный слесарь: на глаз определит размер гайки, за минуту подберёт ключ, затем еще минуту потратит на закручивание. Итог: работу делает быстро и правильно, если нужно, то напишет документацию по закручиванию гаек, а также без проблем научит неопытных.
Плохой опытный слесарь: а нахрена эту гайку закручивать – забью молотком, тысячу раз так делал, и всё всегда было ок. Итог: работу делает быстро, но неправильно.
— Постоянный недосып (не секрет, что многие работают по 10-12 часов в сутки) может сказаться на притуплении внимания в конце рабочего дня и стать причиной к примеру автокатастрофы с летальным исходом.
— Постоянные стрессы (вызванные вечной гонкой, дедлайнами и т.п.) ведут к сердечным заболеваниям ближе к старости и как следствие к ранней смерти.
— Сидячий образ жизни ведёт к болям в спине и геморрою (не смертельно, но может сильно подпортить жизнь).
— Повышенная нагрузка на глаза (к счастью, ослепших айтишников пока ещё не видел, а вот очкариков знаю достаточно много).
Вспомнился старый анекдот, услышанный когда-то в Черногории...
Приезжает в Черногорию американец. И каждый день видит с балкона своей виллы одно и то же: мужик сидит на берегу моря с хлипкой удочкой. Поймает за день пару рыбешек и довольный идет домой.
Американец не выдерживает и подходит к рыбаку:
— Слушай, парень, а почему бы тебе не купить удочку получше?
— Зачем?
— Ну как? Поймаешь больше рыбы, начнешь ее продавать.
— Зачем?
— Заработаешь денег и откроешь лавку.
— И что?
— Как что? Капитал появится, сможешь лодку купить. Наловишь в сто раз больше, чем сейчас…
— И что?
— Разбогатеешь и сможешь наконец никогда больше не работать…
Местный смотрит на него, как на придурка, и говорит: Ты что, не видишь? Я и так не работаю!
А вам не кажется, что минусовать вопрос глупо, при этом даже не приведя ссылки на какой-нибудь мануал в пользу других решений хотя бы с минимальным анализом затраченных ресурсов (как железных, так и временных на разворачивание)?
Надеюсь, все правильно поняли, что фраза «перед разработчиками PHP встаёт задача» имеет отношение именно к фазе разработки, а не к продакшн?
Разве конфигурирование этой связки сравнится с элегантностью решения, которое предоставляет Docker: одна консольная команда в Docker — run (ну или 3 что у меня) против N команд связки lxc+ansible?
По мне так автор сделал прекрасный «Hello, world», который можно положить в основу для создания умного дома — т.е. управления фактически всеми электрическими устройствами с мобильного телефона!
В системах мониторинга ИТ-проектов проблема игнорирования встречается не редко. И порой она связана не только с ложными срабатываниями, но и неправильным выбором настроек системы мониторинга.
Схема простая:
1. Руководитель предлагает: а давайте отслеживать такой-то параметр системы (в данном примере он не является критическим).
2. Админ аккуратно настраивает сбор данных по обозначенному параметру. На данном этапе все довольны: система собирает информацию, которая аккуратно складируется в базу данных и никого не отвлекает.
3. Но в какой-то момент руководитель вдруг решает, что админу неплохо было бы получать уведомления, если отслеживаемый параметр превысит определённое значение, и по каждому случаю срабатывания проводить расследование.
4. Админ настраивает уведомления. Но вот беда, уведомления приходят по 10 раз в сутки, причём не только в рабочее время на панель мониторинга, но и во время отдыха на телефон (не все компании могут позволить круглосуточное дежурство).
5. Через несколько дней админ просто выключает телефон перед сном, игнорируя не только уведомления по параметру п.1, но и все остальные.
Чтоб подобного не случалось, нужно ещё на этапе проектирования системы мониторинга все параметры разбить на группы:
1. Незначительные — информация собирается, но никак не проявляется. В Zabbix это обычный элемент данных (Item) без триггера (Trigger). Данная группа параметров никак не влияет на работу системы и может использоваться для получения дополнительных сведений (например, при расследовании падений или оптимизации).
2. Информационные — информация собирается и отображается в панели мониторинга. На примере Zabbix: элемент данных + триггер, но без действия (Action). Данные параметры не приведут к моментальному краху системы, но важны для прогнозирования и предотвращения падений в будущем.
3. Критические — информация собирается, факты превышения пороговых значений сразу же отображаются в панели мониторинга, а админу отправляется уведомление. В Zabbix: элемент данных + триггер + действие. Только при приближении к критической ситуации нужно дёргать админа в нерабочее время, и только так можно добиться, чтоб он даже не задумывался об игнорировании уведомлений.
:)
Как-то мне приходилось работать админом в компании, занимающейся хостингом. В большинстве случаев, количество сайтов на сервер колебалось от 20 до 100. А вот совокупная нагрузка как раз таки была не очень большой и колебалась в пределах 0...10 запросов в секунду (в зависимости от времени суток), что в принципе и логично: серьёзные высоконагруженные проекты обычно на виртуальном хостинге не размещают.
Специально для вас сделал простое нагрузочное тестирование тестового виртуального сервера: 1 CPU / 1Gb Ram / 4 Gb swap SSD. Характеристики выбрал, чтоб максимально переложить нагрузку на своп. На сервере Ubuntu 18 LTS, Nginx, Php7.2-fpm, Mysql, в качестве приложения сайт на Wordpress с 50 страницами.
1. Останавливаем Nginx, Php-fpm:
2. Запускаем простой скрипт, чтоб забить память и уйти в своп:
Ждём, чтоб оперативка полностью забилась (к примеру, можно отследить в другом терминале через htop) и останавливаем скрипт Crtl+Z (скрипт нужно именно остановить, а не убить посредством Ctrl+C, чтоб данные остались в памяти).
3. Запускаем Nginx, Php-fpm:
Теоретически, система им должна выделить память в свопе.
4. Открываем локально 5 терминалов и в случайном порядке запрашиваем страницы в бесконечном цикле:
Как результат мы создали нагрузку примерно 5 запросов в секунду. Да, сервер тормозит, что в принципе логично. Но задержка не 30 секунд (необходимо для ошибки 503 при дефолтном max_execution_time), а всего 1-3 секунды. Как я и писал выше: да, сервер тормозит, но отвечает. Из-за пары секунд ожидания на интервале 5-10 минут (пока админ фиксит проблему) клиент точно не уйдет к конкурентам. А вот если в браузере ошибка 502, то у него не будет никаких оснований чего-то ждать.
Я и НЕ ПИСАЛ, что использование свопа для штатных задач — это круто. Но своп позволяет избежать краха системы, если что-то пошло не так, и какой-нибудь процесс сожрал слишком много памяти. Своп — это как буфер, использование которого даёт админу запас времени, чтоб решить проблему.
Да, система будет тормозить, НО РАБОТАТЬ! Думаю, многие со мной согласятся, что это гораздо лучше для репутации, чем ошибки в браузерах клиентов.
Далее, настраиваете метрику для Заббикс, которая будет сообщать админу, что сервер залез в своп. А уже админ руками убъёт (или перезапустит) жадный процесс.
После этого останется всего лишь выполнить 2 команды, которые пренесут оставшиеся в свопе данные в оперативку:
А настроить своп религия не позволяет?
Если кому интересно, то цены на исходящий трафик можно оценить по следующим ссылкам:
Azure: azure.microsoft.com/ru-ru/pricing/details/bandwidth
AWS: calculator.s3.amazonaws.com/index.html
А как вы прокомментируете наличие уязвимостей в вышеобозначенной версии OpenSSL, которые были закрыты заплатками в версии 1.0.1k в начале 2015 года?
Имеете ввиду отправлять открытый ключ или его отпечаток через другой канал связи (почта, месенджер и т.п.)?
Vindicar, именно так вначале и планировалось, но потом получилось, что контента про SSH гораздо больше, чем про практические аспекты.
Про заголовок замечание справедливое, в ближайшем будущем подправлю!