Comments 39
>модифицированный командный интерпретатор bash
зачем?
зачем?
+7
На тот момент мы использовали старую версию операционной системы openSUSE и, как следствие, старую версию bash «из коробки». Вместо того, чтобы обновить bash целиком, решили бэкпортировать необходимый функционал из новой версии. В процессе изменений была допущена ошибка.
На данный момент bash обновлён целиком.
На данный момент bash обновлён целиком.
+4
Уточню, что забэкпортить необходимые изменения на тот момент выглядело проще, чем обновляться на новую ветку. В итоге мы всё равно обновились на новую ветку, что потребовало фиксить синтаксис некоторых системных и наших скриптов, но это уже другая история.
+6
>В модифицированном нами коде bash
Как вы старательно раскладываете грабли…
Как вы старательно раскладываете грабли…
+24
там выше коллега ответил про баш:
habrahabr.ru/company/odnoklassniki/blog/268413/#comment_8604787
habrahabr.ru/company/odnoklassniki/blog/268413/#comment_8604787
0
Вот поэтому я и не люблю языки программирования, в которых синтаксис активно зависит от непечатаемых символов ( python и т.п. ).
Я на подобное нарвался с какой-то древней утилитой (возможно make или что-то совсем экзотическое) еще учась в ВУЗе, на какой-то лабораторной работе. Что-то работало совершенно не так только от того, что где-то стояла табуляция вместо пробела.
Итого, единственный правильный способ обработки непечатаемых символов (пробелов, табуляций, переносов строк и возвратов каретки) в программах — пропускать их идущие подряд в любом порядке и в любом количестве и считать это одним «виртуальным разделителем».
Я на подобное нарвался с какой-то древней утилитой (возможно make или что-то совсем экзотическое) еще учась в ВУЗе, на какой-то лабораторной работе. Что-то работало совершенно не так только от того, что где-то стояла табуляция вместо пробела.
Итого, единственный правильный способ обработки непечатаемых символов (пробелов, табуляций, переносов строк и возвратов каретки) в программах — пропускать их идущие подряд в любом порядке и в любом количестве и считать это одним «виртуальным разделителем».
+15
> python и т.п.
Просто не надо заставлять уборщицу вносить изменения в код. Для Python есть куча линтеров, PEP8 и прочее. При наличии адекватно настроенного редактора ошибиться с чем-то типа пробела или отступа невозможно. Специалисты это знают и умеют.
Просто не надо заставлять уборщицу вносить изменения в код. Для Python есть куча линтеров, PEP8 и прочее. При наличии адекватно настроенного редактора ошибиться с чем-то типа пробела или отступа невозможно. Специалисты это знают и умеют.
-12
Позволю не согласиться. Везде, где присутствует ручная работа, возможны ошибки. Это аксиома.
Чем больше граблей разложено в системе, тем больше шанс получить по голове. Вероятность не наступить ни на одни грабли падает в геометрической прогрессии с ростом числа граблей и числа прохожих (сотрудников). Если один человек наступает на одни грабли с вероятностью 0.01% в год, то хотя бы один из 100 человек наступят хотя бы раз на одни из 100 граблей — 1-(0.9999^100)^100 = 63% (упс!)
Проблемы необходимо устранять системно — раз и навсегда, чтобы не оставлять ошибкам ни единого шанса.
Чем больше граблей разложено в системе, тем больше шанс получить по голове. Вероятность не наступить ни на одни грабли падает в геометрической прогрессии с ростом числа граблей и числа прохожих (сотрудников). Если один человек наступает на одни грабли с вероятностью 0.01% в год, то хотя бы один из 100 человек наступят хотя бы раз на одни из 100 граблей — 1-(0.9999^100)^100 = 63% (упс!)
Проблемы необходимо устранять системно — раз и навсегда, чтобы не оставлять ошибкам ни единого шанса.
+20
> Это аксиома.
Я не про ошибку вообще, а конкретно про «синтаксис активно зависит от непечатаемых символов». При использовании правильно настроенного редактора это не проблема, т.к. всё выявляется автоматически. Поэтому и нужны стандарты кодирования.
Понятно, что когда уборщица садится фиксить фантазии велосипедиста, то получается некрасиво.
Я не про ошибку вообще, а конкретно про «синтаксис активно зависит от непечатаемых символов». При использовании правильно настроенного редактора это не проблема, т.к. всё выявляется автоматически. Поэтому и нужны стандарты кодирования.
Понятно, что когда уборщица садится фиксить фантазии велосипедиста, то получается некрасиво.
-3
Надо чтобы было хорошо и при наличии правильно настроенного редактора, и при его отсутствии.
В жизни ведь всякое бывает, иногда и в «полевых условиях» приходится код править. Редакторы — их много, они разные (кому-то удобен один, кому-то другой), иногда проприетарные (т.е. любой так просто не скачаешь), иногда под разные ОС (и под нужную в данный момент может не оказаться), иногда они перестают поддерживаться и т.д. И код может переходить из рук в руки, из компании в компанию и т.д., а везде редакторы разные.
В жизни ведь всякое бывает, иногда и в «полевых условиях» приходится код править. Редакторы — их много, они разные (кому-то удобен один, кому-то другой), иногда проприетарные (т.е. любой так просто не скачаешь), иногда под разные ОС (и под нужную в данный момент может не оказаться), иногда они перестают поддерживаться и т.д. И код может переходить из рук в руки, из компании в компанию и т.д., а везде редакторы разные.
+9
UFO just landed and posted this here
UFO just landed and posted this here
В статье как-то ничего не сказано о дальнейшей судьбе дежурного администратора, как он такой стресс перенёс?
+14
Все с ним было хорошо. По итогам аварии никто не был уволен — починили и сели разбираться с найденными проблемами и рисками.
+11
никого не уволили? серьезно?
ну премию хоть кому-нибудь дали? хоть один достойный человек купил себе машину по результатам восстановления бизнеса?
ну премию хоть кому-нибудь дали? хоть один достойный человек купил себе машину по результатам восстановления бизнеса?
0
Так вопрос не об увольнении, а о компенсации работодателем потери нервных клеток работником.
Оффтопик: даёшь классификацию профессии системного администратора как тяжелую/нервную с сокращённым сроком для выхода на пенсию; расширенным отпуском; обязательными командировками в санатории!
Оффтопик: даёшь классификацию профессии системного администратора как тяжелую/нервную с сокращённым сроком для выхода на пенсию; расширенным отпуском; обязательными командировками в санатории!
0
Переведен в дата центр в Магадане
+11
В модифицированном нами коде bash оказался другой баг, из-за которого интерпретатор при обнаружении пустой строки в конце конфигурационного файла входил в бесконечный цикл и переставал отвечать на внешние команды.А зачем вообще трогать системный bash? #!/usr/local/super_bash/bin/bash прекрасно справляется с задачей установки подходящего интерпритатора для скрипта.
Да и невозможность штатного обновления выглядит странно. Для меня это звучит примерно так: «скрипты были написаны абы как, без соблюдения требований и стандартов».
И, кстати, очень хотелось бы взглянуть на пример кода, который заставлял отказываться от обновленных версий в пользу ручной модификации кода интерпритатора (для самообразования, что бы так не делать)
+1
из статьи не понял, сможете ли вы сегодня произвести холодный запуск системы, появился ли кейс с периодическим перезапуском подсистем для избегания указанной проблемы с носителями и инициализацией?
+1
Зависимости, мешающие холодному запуску — устранены. Новые и существующие системы тестируются на наличие подобной проблемы. Есть возможность проблемные системы отключать, на тот случай если в production всетаки попадет проблемный код. И это тоже тестируется. Тестирование перезапуском по питанию специально не проводим, но это иногда случается :)
+2
Хорошая статья, спасибо!
+2
А сейчас что случилось?
+6
В одной известной мне компании, скрипты пишутся уже около 15-ти лет на /bin/sh. Проблем с несовместимостью не было ни разу. Баш — зло для скртиптинга в продакшне.
+2
Разработчик, создававший и тестировавший шаблон
Но дежурный администратор правил файл шаблона в другом редакторе, который поместил этот символ в конец файла
То есть критично важный код пишут и тестируют одни и те же люди, а потом другие люди еще его правят? Блестяще организованный процесс обеспечения качества, есть чему поучиться.
Понятно почему у вас бажные скрипты выполняются в бажном кастомном интерпретаторе, а потом все валиться.
Потом, пункт два:
Одноклассники состоят из примерно 150 подсистем (различные базы данных, серверы бизнес-логики, кэши, графы, фронтэнды, системы конфигурации и т.д.). И работоспособность практически каждой подсистемы зависит от доступности других.
Вы считаете это хорошей архитектурой?
В извлечении уроков я не увидел ничего, касающегося пересмотра архитектурных подходов.
P.S. Избавьте от этих вопросов для самопроверки, в данной ситуации на двоешников похожи больше вы.
-8
Расскажите же, какая должна быть архитектура.
+7
Чем меньше точек отказа, тем лучше. Ваш, Кэп.
150 программных точек отказа — действительно очень много. Возможно, в статье имелось в виду другое.
150 программных точек отказа — действительно очень много. Возможно, в статье имелось в виду другое.
0
Всё правильно: любому проекту хватит и трёх подсистем: nginx + PHP + MySQL.
Если серьёзно, под подсистемами имелись в виду модули со своей кодовой базой, своим кластером оборудования и своей конфигурацией.
150 подсистем — не значит 150 точек отказа. Наоборот: если ломается один модуль, он не ломает весь портал, а влияет лишь на небольшую часть функциональности.
Раньше это было не совсем так, о том в статье и речь, но после проделанной работы над ошибками подсистемы стали куда более независимыми в плане обслуживания.
Если серьёзно, под подсистемами имелись в виду модули со своей кодовой базой, своим кластером оборудования и своей конфигурацией.
150 подсистем — не значит 150 точек отказа. Наоборот: если ломается один модуль, он не ломает весь портал, а влияет лишь на небольшую часть функциональности.
Раньше это было не совсем так, о том в статье и речь, но после проделанной работы над ошибками подсистемы стали куда более независимыми в плане обслуживания.
+2
Одноклассники состоят из примерно 150 подсистем (различные базы данных, серверы бизнес-логики, кэши, графы, фронтэнды, системы конфигурации и т.д.). И работоспособность практически каждой подсистемы зависит от доступности других.
Так 150 подсистем не означает 150 точек отказа всей системы. В идеальной системе все части должны быть не зависимы. В этом случае отказ одной из 150 частей не окажет влияния на остальные и пострадает небольшая часть функционала.
Можно иметь 1 большое хранилище данных и при его отказе из за бага потерять весь сайт, а можно иметь 50 и потерять 1/50.
При этом для обслуживания текущей нагрузки серверов будет примерно столько же, т.е. количество железных точек отказа будет одинаковое.
С другой стороны количество програмных точек отказа скорее связано с объёмом кода, сложностью задач, уровнем квалификации. И скорее всего багов в системе которая разделена на модули будет меньше, чем в одном большом.
В реальности конечно нельзя построить такую идеальную систему, где нет взаимосвязей, но к этому надо стремиться. Одноклассники как раз пытаются сделать так, что бы эффект от програмных и железных отказов был как можно более локализован.
+2
Ждем постов про сегодняшний сбой! :)
+1
А найдется перевод статьи на eng? Хотел отправить коллегам, а перевод не нашел.
Если нет, задумайтесь о переводе. Я уверен, каждой второй вашей статье обеспечено место в топе на hackernews :)
0
На данный момент завершён переход на системы на базе Cassandra и Voldemort.
Как корабль назовёшь так он и поплывёт
0
Sign up to leave a comment.
Три дня, которые потрясли нас в 2013