Скорость работы вашего сайта, его стабильность и отказоустойчивость всегда зависят от трех составляющих:

1. Платформа (CMS) и ее настройки, которые влияют на производительность (параметры кэширования и т.п.)
2. Конфигурация сервера (реального физического или виртуального) и настройки системного ПО (веб-сервер, база данных и т.д.)
3. Качество разработки, кода, интеграции с платформой.

Зачастую веб-разработчик может написать хороший качественный код, но при этом мало что смыслит в системном администрировании и настройке серверов. А хороший сисадмин редко бывает по совместительству еще и классным программистом.

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

В итоге сайт может «хромать» из-за проблем и «узких» мест в любой из составляющих: CMS, хостинг, разработка. Клиент в нюансы не вникает и остается не удовлетворен проектом в целом. Его негатив переносится на всех: «Тормозной хостинг! Ужасная система! Разработчики ничего не умеют!»

Такая картина нас, конечно, никогда не устраивала. И мы решили, что надо что-то делать…

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

Цель данной статьи, показать принцип дешифровки, зашифрованных скриптов, чтобы например расшифровать залитый злоумышленником вирус на PHP.

Закончился Форум технологий Mail.Ru Group 2011, и теперь самое время рассказать об «изнанке» самого мероприятия. Думаю, это может быть многим интересно и полезно.

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

Расскажу о следующих темах:

• Все о посетителях: расчеты, статистика, рекомендации, выводы, как оценивалась явка, как боролись с очередями, конвертация трафика и т.д.
• Все о видеотрансляции: ПО, оборудование, как удалось опубликовать первые видео меньше, чем через час после доклада, какие были проблемы, как решали и т.д.
• Все о фотосъемке-онлайн: как работает система публикации фото в реальном времени.
• Прием вопросов через Twitter/SMS/сайт
• Cтенографирование в реальном времени: ПО, проблемы, решения.

Коллеги, добрый день!

Сегодня поговорим о причинах, побуждающих создавать и внедрять методики и инструменты обеспечения качества, заглянем в историю проблемы, осветим известные риски и постараемся «устаканить» в сознании выигрышную стратегию обеспечения достаточного качества веб-решения. В заключении я расскажу о новом инструменте в 11 версии платформы Битрикс — «Мониторе качества».

Как часто мы сталкиваемся с тем, что во время заполнения тех или иных форм на сайтах, при написании больших текстов в блоге или на форуме внезапно «зависает» компьютер. Или «пропадает» интернет. Или палец случайно попадает по навигационным кнопкам (например, «Назад»), которые так «услужливо» располагают производители ноутбуков и клавиатур в самых неудобных местах.

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

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

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

Я предполагаю, что читатель уже знаком с тем, что такое mod_rewrite, и не буду описывать его основы, которые легко найти в интернете. Также нужно отметить, что в статье освещается работа mod_rewrite при использовании его директив в файле .htaccess. Отличия при работе в контексте <VirtualHost> изложены в конце статьи.

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

Почему так происходит?

Все, наверное, хоть раз слышали, что в России с 2011 года отменен переход с летнего время на зимнее. Чем же это грозит каждому из нас — и администраторам большого количества серверов в сложных системах, и обычным пользователям, имеющим один компьютер и мобильный телефон? Что случится в ночь с 29 на 30 октября 2011 — до которой осталось, кстати, всего 2 недели?

Новый Федеральный закон Российской Федерации от 3 июня 2011 г. N 107-ФЗ «Об исчислении времени»:

• принят Государственной Думой 2011-05-20
• одобрен Советом Федерации 2011-05-25
• опубликован 2011-06-06
• подписан президентом 2011-06-09
• вступил в силу с 2011-08-07

Чем же грозят нам эти изменения и что от этого может сломаться?

К написанию сей заметки меня сподвигло то, что я устал делать развёрнутые замечания на эту тему в комментариях к статьям, где в качестве части инструкции по сборке и настройке чего-либо для конкретного дистра предлагают выполнить make install.

Суть сводится к тому, что эту команду в виде «make install» или «sudo make install» использовать в современных дистрибутивах нельзя.

Но ведь авторы программ в руководствах по установке пишут, что нужно использовать эту команду, возможно, скажете вы. Да, пишут. Но это лишь означает, что они не знают, какой у вас дистрибутив, и дистрибутив ли это вообще, может, вы вступили в секту и обкурилисьчитались LFS и теперь решили под свою хтоническую систему скомпилять их творение. А make install является универсальным, хоть и зачастую неправильным способом это сделать.

Для многих крупных высоконагруженных веб-проектов зачастую «узким» местом в производительности становится скорость работы базы данных. Можно добавлять память, тюнить те или иные параметры… Но в итоге чаще всего всё упирается в диск.



Мы и сами на собственных проектах сталкивались с подобными «бутылочными горлышками» (bottleneck), периодически наблюдая близкую к 100% утилизацию диска в iostat.

О нашем опыте решения этого вопроса и хотим рассказать вам в этом посте…

Этой статьей мы открываем целый цикл постов, посвященный новинкам, реализованным в новой, 11-ой версии «1С-Битрикс: Управление сайтом».

Одна из самых интересных возможностей, появившаяся в новом релизе, — поддержка облачных хранилищ.



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

Мы рады представить сообществу «Хабрахабра» наш новый сервис — Облачное Хранилище. Как и все решения подобного класса, оно предназначено для хранения и быстрой раздачи статического контента — в том числе контента веб-сайтов.

Те, кто посетил прекрасную конференцию Highload++, имели возможность, в числе прочего, услышать наш доклад про то, как устроено хранилище. Краткое изложение того, о чем мы говорили, мы предлагаем уважаемой аудитории «Хабрахабра».

Чуточку ликбеза. Навеяно предшествующими копипастами разной чепухи на данную тему. Уж простите, носинг персонал.

IP-адрес (v4) состоит из 32-бит. Любой уважающий себя админ, да и вообще айтишник (про сетевых инженеров молчу) должен уметь, будучи разбуженным среди ночи или находясь в состоянии сильного алкогольного опьянения, правильно отвечать на вопрос «из скольки бит состоит IP-адрес». Желательно вообще-то и про IPv6 тоже: 128 бит.

Обстоятельство первое. Всего теоретически IPv4-адресов может быть:
2³² = 2¹⁰*2¹⁰*2¹⁰*2² = 1024*1024*1024*4 ≈ 1000*1000*1000*4 = 4 млрд.
Ниже мы увидим, что довольно много из них «съедается» под всякую фигню.

Записывают IPv4-адрес, думаю, все знают, как. Четыре октета (то же, что байта, но если вы хотите блеснуть, то говорите «октет» — сразу сойдете за своего) в десятичном представлении без начальных нулей, разделенные точками: «192.168.11.10».

В заголовке IP-пакета есть поля source IP и destination IP: адреса источника (кто посылает) и назначения (кому). Как на почтовом конверте. Внутри пакетов у IP-адресов нет никаких масок. Разделителей между октетами тоже нет. Просто 32-бита на адрес назначения и еще 32 на адрес источника.

Прочитав много литературы по истории бизнеса и наблюдая рост популярности Интернет-торговли, автору этих строк хотелось реализовать свои знания на практике. Искали подходящую тему для проекта. Необходимыми условиями были:

1) Вложение не более $10 000
2) Прибыль не менее $1 000 в месяц
3) Минимальная рутина

По первым двум пунктам все понятно. А вот по третьему пункту поясню. К тому моменту я уже работал в собственной компании (сфера финансов). Это был 2009 год. Последствия кризиса еще сильно влияли на основной бизнес и работы было непочатый край. Много времени отвлекать на сторонний бизнес автор не мог.
Подходящий случай подвернулся в октябре 2009 года.

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

Ситуацию усугубляет наблюдаемое ныне противостояние распространенного заблуждения, что в облаке все очень надежно и можно крепко спать: жесткие диски «из титана», сетевой трафик течет «по золотым проводам», а инженеры там крутые парни из Челябинска, рассекающие писсуар пополам — с рекомендациями облачного провайдера на тему «мы предоставляем сервисы достаточной надежности и быстрые каналы между ДЦ, а задача архитектора проекта — комбинировать наши технологии, доводя девяточки справа до нужного количества».

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

22 августа Amazon анонсировал новый сервис в AWS — Amazon ElastiCache. На Хабре об этом тоже написали.

Сервис совмести по протоколу с Memcached.

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

Вступление.

Хочу вам рассказать про наш опыт запуска маркетплейса – каталога различных дополнений и готовых решений для платформы 1С-Битрикс.

Тема сегодня весьма популярна – любая большая платформа имеет свой магазин готовых решений, разрабатываемых партнерами. Ходить далеко за примерами не надо – Apple App Store, Android Market, маркетплейсы браузеров, даже у Skype есть свой магазин:).

На рынке CMS (особенно опенсорсных) тоже есть огромное количество примеров готовых решений, поддерживаемых сообществом. Наверно, это единственный путь развития любой платформы – самостоятельно разрабатывать модули на все случаи жизни нереально, а если у тебя за спиной есть сообщество из тысяч разработчиков – стоит дать им такую возможность самореализоваться.

Мы дали :)

На последнем РИФе я рассказывал об «облаке» как альтернативе традиционному хостингу (на примере Амазона).

С тех пор прошло несколько месяцев. За это время я многократно дискутировал как с ярыми противниками «облака», так и с не менее активными сторонниками.

Последний такой спор случился пару дней назад непосредственно с хостерами. И закончился (с их стороны) примерно таким выводом: «Сейчас облако в хостинге — маркетинговое зло, которое только путает людей».

Тема, как мне кажется, не просто популярная и интересная, но и очень важная. Поэтому я хотел бы обобщить свой собственный опыт (у меня есть несколько личных сайтов на виртуальном shared хостинге, периодически по знакомству присматриваю за одним дедиком, а все рабочие проекты размещены в «облаке» Амазона) и вместе с вами постараться разобраться во всех плюсах и минусах облачного хостинга по сравнению с традиционным.

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

Если вы сами проводили конкурсы и всё было ок — не читайте топик. Если где-то ждал облом — добро пожаловать под кат.

Почти на каждом сайте разработчиков платных тиражных CMS есть раздел «Сертифицированные хостинг-провайдеры», или «Рекомендуемые хостинги», или просто «Хостинги».



Разработчик CMS проверяет соответствие характеристик тестового тарифа, предоставленного хостером, минимальным техническим требованиям своей CMS. В идеале – устанавливает на этом тестовом тарифе свою систему и выполняет базовые операции.

Хостинг-провайдер попадает в список протестированных (сертифицированных) хостеров… и – обычно – на этом все взаимодействие с ним и заканчивается.

Зачем терять время на разговоры о качестве?

Вам нужно в короткие сроки запустить веб-проект, вы выбираете платформу Битрикс или другой фреймворк, подрядчика/интегратора (либо делаете силами собственных программистов), делаете веб-сайт и в час X посетители начинают пользоваться веб-решением.
Зачем отвлекаться на вопросы качества интеграции, если веб-проект запущен и цель, казалось бы, достигнута? Сайт доступен для клиентов, проект реализован почти в срок и уложился в бюджет, премии получены… :-)
Многие просто не задумываются о дальнейшем развитии веб-проекта. А некоторые категории менеджеров откровенно преследуют цель запустить веб-решение в срок и им попросту «наплевать» на качество и дальнейшую судьбу веб-сайта (проект можно попросту передать другому менеджеру).