Готовимся к любым падениям

Это продолжение цикла публикаций, посвященных вопросам планирования аварийного восстановления. В предыдущей статье речь шла об определении зоны планирования и нахождении точек отказа, которые могут приводить к сбоям в работе пользовательских сервисов. Следующий шаг – опираясь на информацию о точках отказа определить минимально возможные сроки устранения инцидентов, которые могут обеспечить технические специалисты при наличии всех необходимых ресурсов.

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

Доброго времени суток, дорогие читатели!

Хочу рассказать вам об интересной задаче, которая стала передо мной в рамках проекта и, естественно, о ее решении.

Исходные данные:
Стандартный набор LAMP (далее СС),
Yii framework (версия здесь не важна),
удаленный сервер (далее УС), на котором установлен демон Sphinx, searchd.
На УС создан пользователь с правами рута (но не сам рут).
На СС установлен модуль ssh2_mod для PHP.

Сразу оговорюсь, в этой статье я не буду расписывать особенности Sphinx, кому интересно, могут почитать официальный мануал sphinxsearch.com/docs/current.html.
Ограничусь только общей информацией.

Итак, Sphinx — поисковый демон, в моем случае работает с MySQL. Основная особенность — он индексирует базу по определенным запросам (описанным в конфиге сфинкса), и результат выборки сохраняет в свои файлы. Чтобы информация была актуальной (в MySQL возможно и добавление и редактирование записей), нужно запускать индексацию сфинкса. Тогда, он сделает повторную выборку и сохранит ее себе.

Задача:
Запускать индексацию сфинкса на УС.
Причина именно удаленного запуска состоит в том, что необходимо запускать команды по крону с конкретными параметрами, определяемыми в коде. Кроны запускаются с СС.
Т.е. на сервере запускается крон, метод которого выполняет индексацию на УС.

Чуть больше года назад я опубликовал сравнение российских облачных операторов: статья многим понравилась и была полезна. Примерно через полгода я начал получать много отзывов и просьб о том, что неплохо было бы сделать новый обзор, актуализировав данные по ценам, добавив в запрос дополнительные сервисы и дополнив его новыми компаниями. В этот раз в сравнение вошли уже 34 компании (в прошлом году их было более, чем в 2 раза меньше), включая зарубежные сервисы Amazon и Rackspace, а сбор информации занял более двух месяцев.



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

Алгоритмы получения текстур игры Caesar III© и отрисовки города разобраны, осталась самая «сладкая» часть, которая притягивает «древнеримских архитекторов» уже больше 15 лет — игровая логика. Используя различные подходы к анализу игры, выношу на ваш суд результат этого небольшого исследования. Я заранее прошу прощения за большую статью, но, как говорится, слов из песни не выкинешь. В заключении будет несколько слов о судьбе исходников, восстановленных из исполняемого файла оригинальной игры.

Вместо вступления

За основу взята более ранняя прочитанная мной статья на Хабре, которой лично мне оказалось достаточно для понимания механизма policy routing в целом — и катастрофически мало для реализации этого типа маршрутизации на сервере компании. Было 2 серьезных подводных камня, над которыми пришлось работать самостоятельно, и которые нельзя оставить без внимания:

• Сохранение настроек в целом
• Перебивание настроек утилитой Network Manager

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

Определяем места, где стоит подстелить соломку

Отказы в работе информационных систем – события, которые невозможно исключить полностью. Вне зависимости от причин случившегося сбоя, в момент его возникновения на системного администратора ложится груз ответственности по оперативному восстановлению работоспособности не только ИТ-систем, но и бизнеса в целом.

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

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

Привет, Хабраюзер!
В данной теме я расскажу о принципах построения системы request tracker с точки зрения программирования, т.к. это достаточно хорошая система учета заявок и может быть использована на крупном предприятии в качестве helpdesk-системы.

Кому интересно — добро пожаловать под кат.

В работе почти каждого человека непременно есть цифры, от которых зависит всё. Посещаемость сайта, время отклика или количество коммитов — что угодно! И если поместить эти цифры на самое видное место, они сразу становятся либо отличным способом оперативно принимать решения, либо просто наглядным инструментом мотивации. А самый лучший способ сделать это — это собственный дешборд, информационное табло, которое можно повесить на самом видном месте в офисе.

Случилось так что в компании, из-за перебоев электропитания, несколько раз падали сервера, а администраторы узнавали об этом только утром когда сотрудники не смогли приступить к работе.

Основной проблемой стало то, что все уведомления администраторам отправлялись по почте — которая, как можно с легкостью догадатся, тоже лягла.

Тогда у меня и зародилась идея — «А давайте админам звонить в критических ситуациях!»

За реализацией и скриптами — прошу под кат.

В один прекрасный день меня достала необходимости периодически набирать на экранной клавиатуре телефона тексты вроде логинов и паролей. При этом, как оказалось, своё состояние я описал вслух: “Вот бы было клёво нажать на Ctrl+C на компьютере, а потом в телефоне Ctrl+V”.
“Ну тыж программист” – напомнила одна из наших тестровщиц. “Не хватает программы, так напиши!”.

И программа для копирования содержимого буфера обмена с компьютера была написана. Несколько знакомых начали пользоваться ей с удовольствием, нашли баги, были советы… но большинство более дальних знакомых (и незнакомых) выразили недоверие. Мол, “я скопипастю пароль, а ты его к себе утащишь. Или сервак твой взломают…” Не доверяют люди. И правильно делают, наверное, доверие ещё надо заслужить. Поэтому с сегодняшнего дня исходники программы открыты всем и каждому!

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

Мы назвали систему АЗ Сутра. Сутра – это на санскрите «нить», а так же ценное высказывание. Сутра – любая целостная ветвь общения, мне это нравится больше чем thread (тоже «нить», кстати). АЗ – активность и значимость.

Для синхронизации файлов проекта, ведения истории мы используем системы контроля версий, например, Git. Однако, когда у меня встал вопрос о контроле версий структуры базы MySQL — удовлетворяющего решения найти не удалось.
Замечу, во многих фреймворках и ORM существуют необходимые механизмы «из коробки» — миграции, версионность и т.д. А вот для нативной работы с MySQL — приходится все делать ручками. И пришла идея попытаться создать автоматическую систему для отслеживания изменений.

Как вы знаете, поставка контроллеров, к сожалению, отошла от намеченных сроков.

Но сегодня у нас хорошие новости: мы получили собранные платы с завода, и теперь начинаем собирать их в готовые устройства, тестировать и, наконец-то, отправлять!

Старина Сноуден Мюллер говорил: «Верить, в наше время, нельзя никому. Порой даже, самому себе.»
Себе я не верю и пароли забываю начисто.
Онлайн-сервисам для хранения паролей не доверяю.
Есть опенсорсные программы для хранения паролей к ним доверия побольше, но лень их устанавливать, держать у себя, да и большая часть функций мне не нужна.

Vim как менеджер паролей

В данной статье я бы не хотел заострять внимание на принципе работы сборщика мусора — об этом прекрасно и наглядно описано здесь: habrahabr.ru/post/112676. Хочется больше перейти к практическим основам и количественным характеристикам по настройке Garbage Collection в JVM — и попытаться понять насколько это может быть эффективным.

Количественные характеристики оценки эффективности GC

Рассмотрим следующие показатели:

• Пропускная способность Мера, определяющая способность приложения работать в пиковой нагрузке не зависимо от пауз во время сборки и размера необходимой памяти
• Время отклика Мера GC, определяющая способность приложения справляться с числом остановок и флуктуаций работы GC
• Размер используемой памяти Размер памяти, который необходим для эффективной работы GC

Как правило, перечисленные характеристики являются компромиссными и улучшение одной из них ведёт к затратам по остальным. Для большинства приложений важны все три характеристики, но зачастую одна или две имеют большее значение для приложения — это и будет отправной точкой в настройке.

Добрый день.

Для своей первой статьи я выбрал одну из самых успешных своих поделок: HDMI-passthrough аналог Ambilight от Philips, далее я будут называть эту композицию «Атмосвет».

Введение

В интернетах не очень сложно найти готовые/открытые решения и статьи как сделать Амбилайт для монитора/телевизора, если ты выводишь картинку с ПК. Но в моей мультимедиа системе вывод картинки на телевизор c ПК занимает только 5% времени использования, большее кол-во времени я играю с игровых консолей, а значит нужно было придумать что-то свое.

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

Вышла новая версия Sypex Geo 2.2 — очень быстрого алгоритма определения города по IP. Теперь базы данных стали двуязычными (русский и английский), регионы и города теперь привязаны к базе данных GeoNames, и имеют постоянные ID.

Были добавлены ОКАТО коды для городов и регионов России, КОАТУУ для Украины и СОАТО для Беларуси.

Технические подробности

Алгоритм работы Sypex Geo значительно не изменился, были исправлены небольшие ошибки, которые возникали при сильной неравномерности распределения IP диапазонов.

Эти приемы были описаны во внутреннем проекте компании Google «Testing on the Toilet» (Тестируем в туалете — распространение листовок в туалетах, что бы напоминать разработчикам о тестах).
В данной статье они были пересмотрены и дополнены.

Этот пост будет посвящен тому, как легко, просто и быстро (потеряв максимум тридцать минут в налоговой) заполнить и отправить налоговую декларацию за 2013 год (то есть ту, которую надо отправить до 30 апреля 2014 года). Попутно будет разобрано получение доступа в личный кабинет налогоплательщика и какие возможности это даёт. Фактически это пошаговая инструкция как всё это сделать за пару дней.

Всё вышесказанное относится к Налоговой Службе РФ.