У нас на работе как-то был довольно жаркий спор о том, считать ли python 2.7 стабильным. Итоги спора и сам вопрос я оставляю в стороне, а тут я хочу изложить и систематизировать определённые мысли о реальных программах, которые сильно противоречат миру Фон Неймана и Тьюринга.
Мир, в котором работают программисты — это мир правильного кода. Разумеется, в нём есть бесчисленные ошибки, но эти ошибки подлежат исправлению. Если это ошибки в чужом коде, который не исправить, они подлежат документированию и учитыванию в своём коде. Но ошибка — это всегда повод её найти и устранить.
Мир же системного администрирования другой. Тут код, который «какой есть, такой есть». Невозможно даже мельком прочитать исходные тексты всех пакетов даже для самой маленькой и скромной установки. 300+ Мб линукса, исходные коды основных библиотек и программ… Оно в принципе необозримо. Можно знать конкретные программы, конкретные места программ — но невозможно знать весь runtime, всё программное окружение, из которого состоит ОС.
И оно полно ошибок. Можно сколько угодно рассуждать про прелести мат. доказательств кода, но это совершенно не поможет, если сбой обнаружится в проприентарном драйвере видеокарты (казалось бы, и при чём тут сервер?) или сетевой карты с TCP offload.
К проблеме ПО есть совсем другой подход — подход сугубо практический. У нас есть априори багованный код, который иногда работает как мы ожидаем этого.
И вот вокруг этого «иногда» и строится вся концепция «стабильности» и product-ready.
Мы признаём, что программа полна ошибок, и что ошибки могут вызываться ошибками в других программах, сочетанием ошибок и их отсутствием. Иногда мы даже знаем, что две ошибки в разных программах могут взаимно нейтрализовываться.
Мы принимаем это «как есть» и стремимся к такой ситуации, в которой ошибок с большой вероятностью нет. Где ошибок меньше всего? Правильно, там, где тестировали больше всего. Если известно, что foobar 1 2 даёт правильный результат, то вероятнее всего там ошибок нет. Что, кстати, вовсе не означает, что foobar 2 1 отработает правильно. Не говоря уже про foobar -1 -2, foobar 1.2 2, \\windows\path\foobar 1 2, foobar «01» «02» и т.д.
Другими словами, мы начинаем говорить о категории «тестированности ПО». Очевидно, что все варианты со всеми данными протестированы быть не могут — но чем больше определённые ветви кода тестируются, тем выше вероятность, что там мало ошибок.
Итак, чем больше тестирования, тем лучше.
Наибольшее тестирование программы проходят в настройках по-умолчанию и типовых конфигурациях из best practicie. Если нет оснований делать своё — нужно делать типичное.
То же касается и выбора ПО. Если нет принципиальной разницы — нужно использовать то, что предлагается по-умолчанию в дистрибутиве. Не то, чтобы оно было лучше — его просто больше использовали.
Не буду голословным, расскажу маленькую поучительную историю из жизни Селектела: Довольно долго мы использовали python 2.4 (по-умолчанию в centos 5.5). Программисты много канючили и хотели python 2.6, потом грязными хаками (использованием библиотек, которые работают только с 2.6+) практически предъявили ультиматум. После первичного тестирования, было принято решение о принятии 2.6 в рабочую среду.
Большинство наших сервисов реализовано по принципу easy fall — как только программе что-то не нравится, она тут же (контролируемо) завершается и перезапускается внешним сервисом перезапуска. Это решает проблему очень обширной логики обработки временных ошибок (недоступности базы данных, нехватки места и т.д.) и смены управляющих (смена мастера в кластере, в пуле, смена адреса в файле конфигурации т.д.). Одна из программ зависела от мастера пула (который один в пуле) и на остальных серверах пула (слейвах), обнаружив, что мастера нет, спокойно завершалась, перезапускалась (с задержкой) и снова завершалась. Если мастер менялся, то программа на старом мастере завершалась и переходила в режим ожидания, а на новом с небольшой задержкой начинала работать.
На Python 2.4 оно работало замечательно. Пришёл python 2.6… И мы обнаружили значительное потребление процессрного времени простаивающей системой. Виновником оказался именно python2.6 — он стартовал (вместе с новыми библиотеками) существенно дольше, чем python 2.4.
С точки зрения программиста: что за хрень?
С точки зрения системного администратора: обновили ПО на новую версию — огребли неожиданных проблем.
… Кстати, проблему решили специальным условием в программе — по отсутствию мастера она не завершается, а спит и пробует снова, то есть нам пришлось даже поменять архитектуру приложения, частично отказавшись от принципа easy fall.
Казалось бы мелочь, фактических ошибок в коде нет — а последствия есть, и не особо приятные.
Таким образом возникает естественная потребность в консервативности (как было, пускай так и будет) — откуда и появляются «тухлые» дистрибутивы с древним софтом и десятилетними сроками поддержки этого самого софта. Главная причина — боязнь изменений в рабочей среде.
Большинство дистрибутивов линукса можно квалифицировать по степени приверженности к stable. Ключевым принзнаком является то, как обновляется софт — только ли обновления безопасности, или же допустимым является обновление ПО на новые версии без смены версии всего дистрибутива.
Это является водоразделом между разными дистрибутивами Linux: Например, ubuntu позволяет себе менять версии ПО; Debian — нет. Таким образом, Debian более консервативный, и уже только по этому более подходящий к серверному применению. Наиболее консервативным является Red Hat, у которой RHEL 4.2 всё ещё поддерживается. Я не помню точно, но кажется, поддержку систем на linux 2.4 они то ли ещё не закончили, то ли закончили в ближайшее время.
И более того, я могу предположить, что в обозримое будущее RH или кто-то ещё, нацеленный на энтерпрайз рынок выпустит продукт с ещё большим циклом поддержки (лет 15-20). Ради чего? Ради того, чтобы «один раз поставить» и больше об этом не думать.
Кстати, Microsoft, включающая в critical обновления серверной ОС новые версии браузера делает явную глупость, нарушая идеологию стабильности.
Вы знаете, я видел интересную позицию, что в некоторых конфигурациях — нет. Мол, если оно так работает, больше её ни при каких условиях трогать нельзя. И более того, известно несколько случаев из практики, когда security updates ломали функционал ПО.
Однако, общая практика говорит, что обновления с исправлениями ошибок должны устанавливаться. Ключевым отличием обновления с багфиксами от новых версий ПО является отсутствие новой функциональности. Исправляются только ошибки, в остальном (стремсятся к тому, чтобы сохранить) функциональность на том же уровне.
Обратной к стабильности является концепция «bleeding edge». Самая свежая версия. Иногда даже из nightly builds (то есть даже не версия, а промежуточное состояние ПО в ходе разработки). Плюсы у Bleeding Edge на самом деле есть.
Во-первых, вы используете нетипичную версию. То есть с большой вероятностью, её баги ещё никому не известны и под них нет эксплоитов. Во-вторых, багфиксы для вас выходят в первейшую очередь. В третьих новый функционал доступен «из-под пера».
Но цена этого велика — никто не тестировал это ПО (и вы в первых рядах тех падших воинов, из которых складывается стена stable), все его баги, несовместимости, глупости и опечатки — ваши.
Выбор — за вами. Я, например, вполне использую сместь sid и experimental Debian дома (то есть почти тот самый Bleeding Edge), «stable» (относительно) LTS Ubuntu на ноутбуке на работе и stable (без кавычек) Debian/Centos на серверах. Более того, между выходом нового дистрибьютива и моментом обновления на него я предпочитаю выждать несколько месяцев (иногда — вплоть до окончания поддержки старого) — за это время в новом дистрибьютиве исправляют несколько ошибок, решают потенциальные проблемы совместимости и т.д. По-хорошему это должны были делать до момента объявления релизом — но лучше перебдеть, чем поиметь бессонную ночь с разгребанием проблем.
Мир, в котором работают программисты — это мир правильного кода. Разумеется, в нём есть бесчисленные ошибки, но эти ошибки подлежат исправлению. Если это ошибки в чужом коде, который не исправить, они подлежат документированию и учитыванию в своём коде. Но ошибка — это всегда повод её найти и устранить.
Мир же системного администрирования другой. Тут код, который «какой есть, такой есть». Невозможно даже мельком прочитать исходные тексты всех пакетов даже для самой маленькой и скромной установки. 300+ Мб линукса, исходные коды основных библиотек и программ… Оно в принципе необозримо. Можно знать конкретные программы, конкретные места программ — но невозможно знать весь runtime, всё программное окружение, из которого состоит ОС.
И оно полно ошибок. Можно сколько угодно рассуждать про прелести мат. доказательств кода, но это совершенно не поможет, если сбой обнаружится в проприентарном драйвере видеокарты (казалось бы, и при чём тут сервер?) или сетевой карты с TCP offload.
К проблеме ПО есть совсем другой подход — подход сугубо практический. У нас есть априори багованный код, который иногда работает как мы ожидаем этого.
И вот вокруг этого «иногда» и строится вся концепция «стабильности» и product-ready.
Мы признаём, что программа полна ошибок, и что ошибки могут вызываться ошибками в других программах, сочетанием ошибок и их отсутствием. Иногда мы даже знаем, что две ошибки в разных программах могут взаимно нейтрализовываться.
Мы принимаем это «как есть» и стремимся к такой ситуации, в которой ошибок с большой вероятностью нет. Где ошибок меньше всего? Правильно, там, где тестировали больше всего. Если известно, что foobar 1 2 даёт правильный результат, то вероятнее всего там ошибок нет. Что, кстати, вовсе не означает, что foobar 2 1 отработает правильно. Не говоря уже про foobar -1 -2, foobar 1.2 2, \\windows\path\foobar 1 2, foobar «01» «02» и т.д.
Другими словами, мы начинаем говорить о категории «тестированности ПО». Очевидно, что все варианты со всеми данными протестированы быть не могут — но чем больше определённые ветви кода тестируются, тем выше вероятность, что там мало ошибок.
Итак, чем больше тестирования, тем лучше.
Наибольшее тестирование программы проходят в настройках по-умолчанию и типовых конфигурациях из best practicie. Если нет оснований делать своё — нужно делать типичное.
То же касается и выбора ПО. Если нет принципиальной разницы — нужно использовать то, что предлагается по-умолчанию в дистрибутиве. Не то, чтобы оно было лучше — его просто больше использовали.
Не буду голословным, расскажу маленькую поучительную историю из жизни Селектела: Довольно долго мы использовали python 2.4 (по-умолчанию в centos 5.5). Программисты много канючили и хотели python 2.6, потом грязными хаками (использованием библиотек, которые работают только с 2.6+) практически предъявили ультиматум. После первичного тестирования, было принято решение о принятии 2.6 в рабочую среду.
Большинство наших сервисов реализовано по принципу easy fall — как только программе что-то не нравится, она тут же (контролируемо) завершается и перезапускается внешним сервисом перезапуска. Это решает проблему очень обширной логики обработки временных ошибок (недоступности базы данных, нехватки места и т.д.) и смены управляющих (смена мастера в кластере, в пуле, смена адреса в файле конфигурации т.д.). Одна из программ зависела от мастера пула (который один в пуле) и на остальных серверах пула (слейвах), обнаружив, что мастера нет, спокойно завершалась, перезапускалась (с задержкой) и снова завершалась. Если мастер менялся, то программа на старом мастере завершалась и переходила в режим ожидания, а на новом с небольшой задержкой начинала работать.
На Python 2.4 оно работало замечательно. Пришёл python 2.6… И мы обнаружили значительное потребление процессрного времени простаивающей системой. Виновником оказался именно python2.6 — он стартовал (вместе с новыми библиотеками) существенно дольше, чем python 2.4.
С точки зрения программиста: что за хрень?
С точки зрения системного администратора: обновили ПО на новую версию — огребли неожиданных проблем.
… Кстати, проблему решили специальным условием в программе — по отсутствию мастера она не завершается, а спит и пробует снова, то есть нам пришлось даже поменять архитектуру приложения, частично отказавшись от принципа easy fall.
Казалось бы мелочь, фактических ошибок в коде нет — а последствия есть, и не особо приятные.
Таким образом возникает естественная потребность в консервативности (как было, пускай так и будет) — откуда и появляются «тухлые» дистрибутивы с древним софтом и десятилетними сроками поддержки этого самого софта. Главная причина — боязнь изменений в рабочей среде.
Большинство дистрибутивов линукса можно квалифицировать по степени приверженности к stable. Ключевым принзнаком является то, как обновляется софт — только ли обновления безопасности, или же допустимым является обновление ПО на новые версии без смены версии всего дистрибутива.
Это является водоразделом между разными дистрибутивами Linux: Например, ubuntu позволяет себе менять версии ПО; Debian — нет. Таким образом, Debian более консервативный, и уже только по этому более подходящий к серверному применению. Наиболее консервативным является Red Hat, у которой RHEL 4.2 всё ещё поддерживается. Я не помню точно, но кажется, поддержку систем на linux 2.4 они то ли ещё не закончили, то ли закончили в ближайшее время.
И более того, я могу предположить, что в обозримое будущее RH или кто-то ещё, нацеленный на энтерпрайз рынок выпустит продукт с ещё большим циклом поддержки (лет 15-20). Ради чего? Ради того, чтобы «один раз поставить» и больше об этом не думать.
Кстати, Microsoft, включающая в critical обновления серверной ОС новые версии браузера делает явную глупость, нарушая идеологию стабильности.
Нужны ли security updates?
Вы знаете, я видел интересную позицию, что в некоторых конфигурациях — нет. Мол, если оно так работает, больше её ни при каких условиях трогать нельзя. И более того, известно несколько случаев из практики, когда security updates ломали функционал ПО.
Однако, общая практика говорит, что обновления с исправлениями ошибок должны устанавливаться. Ключевым отличием обновления с багфиксами от новых версий ПО является отсутствие новой функциональности. Исправляются только ошибки, в остальном (стремсятся к тому, чтобы сохранить) функциональность на том же уровне.
Bleeding Edge
Обратной к стабильности является концепция «bleeding edge». Самая свежая версия. Иногда даже из nightly builds (то есть даже не версия, а промежуточное состояние ПО в ходе разработки). Плюсы у Bleeding Edge на самом деле есть.
Во-первых, вы используете нетипичную версию. То есть с большой вероятностью, её баги ещё никому не известны и под них нет эксплоитов. Во-вторых, багфиксы для вас выходят в первейшую очередь. В третьих новый функционал доступен «из-под пера».
Но цена этого велика — никто не тестировал это ПО (и вы в первых рядах тех падших воинов, из которых складывается стена stable), все его баги, несовместимости, глупости и опечатки — ваши.
Выбор — за вами. Я, например, вполне использую сместь sid и experimental Debian дома (то есть почти тот самый Bleeding Edge), «stable» (относительно) LTS Ubuntu на ноутбуке на работе и stable (без кавычек) Debian/Centos на серверах. Более того, между выходом нового дистрибьютива и моментом обновления на него я предпочитаю выждать несколько месяцев (иногда — вплоть до окончания поддержки старого) — за это время в новом дистрибьютиве исправляют несколько ошибок, решают потенциальные проблемы совместимости и т.д. По-хорошему это должны были делать до момента объявления релизом — но лучше перебдеть, чем поиметь бессонную ночь с разгребанием проблем.
