Sunday, September 30, 2012

Техника быстрого чтения

Прочитав намедни очередную статью с Хабра о деэффективности, проактивности и прочем трэше, внезапно наткнулся на упоминание о технике быстрого чтения - методике, с которой давно хотелось познакомится поближе. Недолгий поиск в гугле показал, что статей по этой теме не так уж и много. Тем не менее, мне удалось найти архиинтереснейшую советскую книгу с оригинальным названием "Техника быстрого чтения". К сожалению, на 95% книга состоит из воды и выдержек протокола заседания XXVI съезда КПСС. Однако, несколько интересных и, возможно, полезных моментов мне всё же удалось найти.


Цель


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

Кроме того, за скорость надо платить. Цена в данном случае - качество понимания текста. Хорошей считается техника скорочтения, при которой усваивается хотя бы 75% материала.


Ошибки


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


Способы чтения


Читать текст можно разными способами: по буквам, по слогам, словами, предложениями или логическими блоками. Способы, как несложно догадаться, расположены в порядке возрастания эффективности. Последний возможен при развитом периферическом зрении, позволяющем мозгу схватывать весь абзац целиком. Подобно тому, как взрослый человек не читает всё слово целиком, а лишь ограничивается несколькими буквами и их позицией, при достижении некоторого уровня дзена можно научится читать текст не словами, а абзацами. Теоретически. Говорят, что Ленин, Маркс и какой-то рабочий с Ульяновского завода могли :)


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


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


Алгоритмы чтения


Что же касается методик: то тут можно выделить два алгоритма техники быстрого чтения: интегральный и дифференциальный.

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

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


Память


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


Используемая литература


1. Кузнецов О. А., Хромов Л.Н. Техника быстрого чтения. М., 1983.

Read more...

Saturday, September 8, 2012

Ошибки при выступлениях и подготовке презентаций

Я не строю иллюзий по части своего ораторского мастерства и прекрасно понимаю, что докладчик из меня средний: есть хуже, есть лучше... Ну и слава богу - есть куда расти и, если что, есть куда падать :) В этой заметке я хочу кратко резюмировать опыт двух моих выступлений (CodeFest 2011, DevDay 09/07/2012), что бы в случае чего не наступить ещё раз на те же грабли.

Начнём с классики - "Смерть через PowerPoint". Шок! Сенсация! - в общем смотреть/читать всем и до конца :)



К первому своему докладу я готовился довольно тщательно и был уверен в его успехе: интересная техническая тема (АОП), не сильно перегруженная презентация с упором на устное повествование и даже подготовка к выступлению перед публикой [*]. В общем ничего не предвещало беды :)

Однако, когда пришло время выступать я жутко перенервничал и выпалил весь доклад буквально за 20 минут, в то время как в спокойной обстановке перед коллегами рассказывал его минут за 40 :) В результате я упустил из рассказа где-то четверть информации. Ту же информацию, что я всё же рассказал, воспринять было довольно сложно, ибо говорил я быстрее, чем бабушки, которые продают "маааааароженноеэскимовшоколаде" в пригородных электричках :)

"Не беда" - подумал я. Всё же - первый раз, в следующий раз точно всё получится. И начал готовить коварный план мести. Много смотрел, как выступают другие, и с каждой увиденным докладом всё больше и больше убеждался в том, что слайды в презентации должны быть как можно проще, понятнее и веселее. Они должны развлекать слушателя (изредка иллюстрировать что-то), тем временем как суть презентации будет доносится словами докладчика.

Именно в этой концепции я и решил построить свою следующую презентацию: максимум смешных картинок и никакого текста на слайдах - всё будет рассказано устно!

Делалась в этот раз презентация дольше: искать весёлые картинки в гугле и обрабатывать их потом в gimp'e оказалось не так занимательно, как я предполагал :) Но чёрт с ним: презентация готова, рассказана нескольким группам людей, получен фидбек, внесены правки. Всё, в бой!

А нет! :) Мандраж никуда не девается. Да, он намного меньше, чем в первый раз, но он есть. Но самое интересное обнаруживается во время доклада:

1. Самая большая ошибка, которую я совершил в этот раз - это рассказ, который не опирается на слайды. В моём случае слайды являлись лишь иллюстрациями, которые могли появится по середине предложения. Я не мог опираться на слайды. Пока я рассказывал доклад в своей зоне комфорта (знакомым, коллегам), это не имело значения. Но как только мандраж немного выбил меня из седла... я бесконечно убедился в том, что рассказ должен опираться на слайды, а не наоборот!

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

3. Ну и последнее. Нельзя, нельзя полагаться на распечатки текстов. Их не должно быть у вас с собой! Они и не нужны, если выполнены два предыдущих пункта! Если у вас случится ступор по середине доклада (что, естественно, со мной и произошло) вы не сможете сколь-либо оперативно найти в своих распечатках нужное место. Слайды - ваши подсказки и распечатки!


Read more...

Особенности разработки enterprise-приложений

Буквально вчера я выступал с докладом на замечательном мероприятии DevDay, проводимым ребятами из 2GIS. Доклад был обзорным и посвящался разработке корпоративного ПО. Под катом прилагаю слайды и текст доклада.
Добрый день! Меня зовут Крестьянинов Михаил. Работаю я в компании XXX, где занимаюсь системой биллинга и внутренней автоматизацией.



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



Кому-нибудь эта картинка что-нибудь напоминает? :) Нет? А я вот каждый день вижу :).

И так, все мы знаем (ну или по крайней мере догадываемся), что представляют собой такие направления разработки как webdev, gamedev... популярный в последнее время mobiledev. Однако, далеко не всем известно, что же представляет собой разработка enterprise (или в переводе на великий и могучий — корпоративных) приложений?

Как видно с этой картинки, занятие это довольно увлекательное, насыщенное разными технологиями, проблемами и их решениями :)

Но что бы ответить на этот вопрос серьёзно, давайте представим себе, что у нас есть некая относительно крупная компания... например, XXX. Жизнь в этой компании бурлит, цветёт и пахнет: подключаются абоненты, оплачиваются услуги, предоставляется интернет, списывается абонентская плата... ну и всё по новой :) Однако, если бы всё это делалось вручную, с помощью специально обученных бабушек или иной биоробототехники, к успеху бы компания шла очень долго и скорее всего никогда бы не дошла.

Что бы автоматизировать все эти бизнес процессы (и списывать ещё больше денег) как раз и используются приложения, именуемые корпоративными: биллинг, система учёта клиентов и т. д. Иначе говоря, корпоративные приложения — это ПО, призванное решать задачи автоматизации бизнес процессов компании.




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



В качестве примера возьмём процесс подключения абонента в НТК. Первым делом счастливый абонент (появляется абонент) звонит по телефону (или иным образом) сообщает оператору (появляется оператор), что хочет подключится. Его контактные данные сохраняются в CRM (появляется CRM) и на их основе создаётся заявка в Issue Tracker (появляется Jira). Заявка в трекере проходит некоторые бюрократические и технические этапы — например установку оборудования монтажником (появляется монтажник). После этого абонент заводится в биллинге (появляется АСР) и конфигурируется на оборудовании (появляется оборудование).

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

На первый взгляд, процесс довольно прост, и не совсем понятно, так ли здесь нужно что-то автоматизировать. Однако, если посмотреть на него более детально...




Думаю, ответ становится очевиден :)



И так, мы ответили на вопрос – Зачем нам корпоративные приложения? Перейдём к вопросу – Откуда берутся корпоративные приложения?



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

Почему? Ответов тут два.




Во первых — это стоимость. Приложения из Oracle E-Business Suite стоят в среднем от 5 до 20 килобаксов, плюс поддержка где-то ешё на тысячу /полторы. С учётом того, что большая часть его функциональности вам не пригодится, покупка его может быть оправдана только в случае компаний неимоверных масштабов.

Конечно же есть и более пролетарские решения. В качестве примера можно взять продукты компании Naumen из ЕКБ. Однако, в данном случае мы наступаем на другую сторону медали — …




… кастомизируемость, адаптируемость продукта под нужды компании.

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

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




И так, мы решили писать своё enterprise-приложение. Какой подход выбрать? Вариантов тут на мой взгляд три.
Первый подход я назвал «Банковским», потому что его реализацию можно встретить практически в любом банке. В основе него лежит святая святых — БД Oracle за несколько сотен килобаксов. Большая часть логики при этом реализована в виде хранимых процедур на PL/SQL. Говорить о недостатках этого подхода смысла нет, так как споры об эффективности процедурной разработки в свете наличия ООП вроде бы давно утихли и остались в прошлом. Понятно, что это наследие прошлого, которое необходимо поддерживать и развивать. Которое приносит деньги.



Далее идут сервера приложений. Довольно интересный подход, который тем не менее редко можно встретить на рынке НСК. Суть его заключается в использовании специального ПО — сервера приложений (типа Jboss, WebSphere), который берёт на себя все аспекты работы с БД, контроля транзакций, авторизации, кластеризации. Разработчику при это остаётся только самое главное — описывать бизнес-логику.

Причина непопулярности данного подхода у нас скорее всего кроется в их цене (до $5К) и относительно невысокой производительности (обусловленной не всегда востребованными накладными расходами). Поэтому зачастую их можно встретить только в крупных компаниях, которые покупали брендовые сервера «под ключ»: с заранее установленной брендовой ОС и сервером приложений. Например, IBM System I c AIX и WebSphere на борту. В качестве более-менее удачного примера использования можно рассмотреть АльфаКлик от АльфаБанка (судя по их вакансиям работает на WebSphere под AS/400).

Ну а что же делать, если не хочется писать хранимые процедуры и нет веры в EE-сервера? Правильно, писать своё — с нуля. На самом деле — шучу. Почти с нуля.




Для разработки корпоративных приложений прекрасно подходят языки со строгой типизацией и мощным фреймворком/комьюнити. Примерами таких языков являются Java с замечательным Spring FrameWork и C# с не менее замечательным .NET. У нас в НТК мы используем как раз Java + Spring, чему очень рады.



Но бог с ней, с теорией — давайте перейдём к практике и попробуем спроектировать своё enterprise-приложение. С блэкджеком и прочими фичами. Как следует из заголовка доклада - это будет биллинг. Заодно я покажу, как он устроен у нас в НТК.

Первым делом давайте определимся с тем, что же должен уметь биллинг. Как минимум хранить информацию об абонентах и предоставляемых им услугам (появляется сервис Абоненты/Услуги).Что бы предоставлять услуги, например, доступ в интернет, придётся научиться конфигурировать оборудование (появляется сервис Оборудование). Раз у нас появились абоненты, которым мы предоставляем услуги, — пора начинать списывать с них деньги! (появляется сервис Тарификация). Что бы абоненты могли пополнять свой баланс и приносить компании ещё больше денег, дадим им возможность пополнять баланс (появляется сервис Приём Платежей). Так же мы должны уметь оповещать абонентов (появляется сервис Нотификации). И предоставить web-интерфейсы для абонентов, операторов и администраторов (появляется сервисы Интерфейсов).

И так мы декомпозировали наш биллниг на несколько относительно независимых служб, реализующих свой модуль бизнес логики. Каждая из них достаточно самостоятельна, что бы быть представлена отдельным приложением с 2х/3х-звенной архитектурой и, потенциально, со своей БД (появляются базы данных).

Такой подход называется сервисно-ориентированным или SOA. Его преимущества достаточно очевидны: кластеризация бизнес-логики, упрощение доработок и рефакторинга, потенциальное масштабирование, и главная ценность для больших систем — порядок!




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

Связать службы можно несколькими способами:
1. Напрямую (появляются прямые связи). Самый простой и самый эффективный способ. По крайней мере при небольшом количестве служб. Спектр возможных протоколов тут крайне широк, но зачастую речь идёт об REST или SOAP. В нашем случае используется крайне специфичный бинарный протокол Hessian, но его наличие обусловлено чисто историческими причинами :)




2. Второй способ - Очереди Сообщений (появляется схема с MQ). Тут существует несколько возможных протоколов: Java Message Service, Advanced Message Queuing Protocol, ну и конечно же Microsoft Message Queuing – лозунг “Not invent here” никто не отменял :) У каждого протокола есть свои реализации (наиболее популярные приведены на слайде), но суть у них одна - асинхронный обмен сообщениями без явного необходимости указания адресата и адресанта.

Например, в нашем биллинге такая схема (на основе ActiveMQ) используется для отработки события подключения абонента. Как только служба работы с оборудованием зафиксирует факт подключения абонента — она отправит сообщение об этом в соответствующий топик. Все другие службы и системы, которые хотят быть в курсе этого события (Учёт Абонентов, Нотификация, JIRA) получат это сообщение и сделают соответствующие выводы. Относительно предыдущего способа у данного есть 3 явных преимущества:
- всегда можно подписать или отписать ещё одну службу на некоторое событие,
- время работы вызывающей службы не зависит от времени работы вызываемых служб,
- работа системы в целом не зависит от доступности вызываемых служб, в виду гарантии доставки сообщения.




3. И последний способ — через сервисную шину предприятия, Enterprise Service Bus (появляется схема с ESB). ESB, как и вариации Message Queuing является стандартом, но уже не обмена сообщениями, а интеграции корпоративных систем. Что бы понять его предназначение, давайте представим себе компанию в которой одна служба имеет интерфейс SOAP, другая — SMTP, а третья — вообще работает только по собственному XML протоколу поверх TCP. Что бы свести всё это к единой схеме, единой шине нам как раз и пригодится ESB приложение (например, eMule), на основе которого мы напишем коннекторы (появляется JIRA и 1С с коннекторами) ко всем службам по всем нужным протоколам, не изменяя при этом ни строчки кода этих служб.

Какой же способ выбрать? Всё зависит от ваших задач. Мы в своей работе используем все три способа. Прямые связи, так как это дёшево и эффективно (тут правда стоит отметить, что большинство наших служб и сервисов самописаны и поддерживают единый протокол Hessian). JMS — в тех случаях, когда бизнес процесс явно подразумевает асинхронную модель поведения. ESB — в качестве моста между Hessian-службами и чужеродными нам Jira/1C.




Вот мы, пожалуй и добрались до самого главного — БД. Данные — это пожалуй одна из самых главных ценностей любой IT компании, а способ из хранения — ценнейшая тайна :) На самом деле нет :)

Но давайте к сути. Какую БД выбрать для вашего приложения?




Обычно всё уже давно выбрано за нас, причём давно :) Однако, если попытаться ответить на этот вопрос теоритически...

Понятно, что модный пару лет назад NoSQL стоит оставить Хипстерам. Ограничения целостности и строгая структурированность данных — крайне важные вещи, при работе с серьёзными данными…




… Что же касается реляционных БД... то тут почти у каждой есть своя Success Story в крупных проектах: MySQL — YouTube, Postgres — Skype, Sybase — SUP, MsSQL — все партнёры Microsoft, Oracle — так вообще корпоративный стандарт.

В общем холиварить тут можно долго. Точно можно сказать, что количество success story и размер comunity у Oracle просто огромны. Однако, он стоит денег — 47 килобаксов за процессор (и это без поддержки!). Что, согласитесь, не мало.

Из бесплатных БД лично нам наиболее импонирует Postgres...




Мы умеем с находить с ним общий язык. Он хорошо зарекомендовал себя в плане работой под нагрузкой в проекте CN.ru. Он умеет партицирование и репликацию, которые так же успешно опробованы как у нас, так и в других российских компаниях, в том же Яндексе. В общем – мы любим и верим в Postgres.

Если же говорить о выборе, то уникального рецепта тут нет. Попробуйте всё сами, сравните и выберите наиболее удобное и эффективное для вас решение.




Однако, как я уже говорил выбирать зачастую не приходится — скорее всего всё уже выбрано за вас! :) Помните, пару слайдов назад я показывал вам, как выглядит структура сервисов нашего биллинга? Так вот - я соврал :) Мы хотим, что бы она так выглядела :)

На самом деле все выглядит так (Спецэффект).

В нашем случае в качестве основной БД мы имеем купленный много лет назад вместе в первым биллингом Sybase.




Недавно у него было день рождение. Ему исполнилось 12 лет. Я в его возрасте в первый раз попробовал пиво :) Нет, это очень хорошая СУБД... для своего времени :) Количество параметров конфигурации и объёмы документации превышают пожалуй размеры любой современной open source БД. Там даже есть партицирование БД (правда только по первичному ключу).

Но! В нём нём крайне скудны возможности SQL (минимум агрегатных функций, ни какой рекурсии или оконных функций), работы с триггерами и т. д. Но это не основная проблема — всегда можно найти какой-то workaround. Основная беда кроется в том, что архитектура БД устарела — нельзя заставить СУБД 12 летней давности эффективно использовать ресурсы современных серверов.

Так как в качестве решения проблемы Sybase предлагает купить последнюю версию их БД по цене не сильно отличающейся от стоимости Oracle, мы решили медленно но верно переезжать на Postgres.

Кстати о переезде. Более менее безболезненный переезд стал возможен как раз благодаря сервисно-ориентированной архитектуре биллинга. Поскольку логика работы с каким-то определённым аспектом инкапсулирована в одной службе, нам относительно безболезненно удалось взять часть таблиц, относящихся к финансам и тарификации и унести их из Sybase в Postgres — к производительности и партицированию, так что остальные службы даже ничего не заметили :)




И так, мы определились с архитектурой и БД. Давайте теперь подумаем, как же тестировать наше приложение?



Когда приложение состоит из одного модуля — всё просто: установили, протестировали. Но что делать, если приложение, сервис зависит от других сервисов? Ответ прост, как и всё гениальное — для каждого тестировщика создавать собственное окружение с блекджеком и полным набором сервисов.

Тоже самое будет касаться и различных БД для сервисов. Правда в нашем случае есть БД, чей объём превышает 100ГБ, что делает её актуализацию несколько затратной. В данном случае можно идти по пути обновления не всей базы, а отдельных таблиц или даже дельт этих таблиц.




Отдельно хотел бы упомянуть модульные тесты... :) Мы все знаем, что TDD - это круто... но давайте смотреть правде в глаза :) Кто из вас положа руку на грудь, скажет что ведёт разработку полностью в рамках этой религии? Писать моки для БД и множества соседних служб, конечно очень увлекательно, но имхо крайне неэффективно. Тем более, если учесть существование тестов интеграционных. В нашей разработке модульные тесты используются только для математики/алгоритмов и некоторых утилит. Всю остальную логику в случае сервисно-ориентированной архитектуры лучше возложить на интеграционные тесты – тут вам и проверка логики и работы с БД, плюс полная имитация всех внешних взаимодействий по всем протоколам, плюс проверка интерфейсов с помощью Selenium.



Для того, что бы автоматизировать процесс тестирования до конца удобно использовать системы непрерывной интеграции, например Hudson. Однако его настройка, это тема для отдельного доклада. Скажу только, что самое сложное при работе с ним — это не забить на него и его репорты. Это требует действительно большой ответственности и силы воли :)



Фух! Потихоньку подбираемся к концу :)



Вкратце затрону процесс выкладки служб на боевые сервера.

Если бы у нас был сервер приложений — то вопрос выкладки и хостинга сервисов отпал бы автоматически. Но у нас OpenSource и Spring :)

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




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

Если говорить о цифрах, то это примерно 150К абонентов, >300К финансовых проводок в сутки и 150ГБ данных.

Кстати про данные. Мало кто знает, но одной из причин появление в 2008 году безлимитных тарифов на интернет в НСК стал тот факт, что с ростом числа абонентов обрабатывать и хранить данные по потреблению трафика стало довольно неоправданно напряжно :)




Проблемы есть у всех. В случае enterprice-разработки они мало чем отличаются от общих по отрасли :)

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

В любой компании есть быдлокод оставшейся с времён, когда компания только начинала развиваться и думать о качестве кода не приходилось. История НТК, например, начиналась с купленного биллинга средней руки на JSP и хранимых процедурах БД и bash скриптах. Сейчас от того биллинга уже ничего не осталось :)

В мире корпоративной разработки есть очень много интересных технологий. Однако, далеко не все нужно использовать. А хочется, ибо круто :) Такую болезнь иногда называют Resume Driven Development. В своей компании видеть такого мне не приходилось, но вот в других порой встречается :)




Ну и конце своего доклада хотелось бы ответить на вопрос, который наверное интересует всех — как сделать так, что бы всё работало и никогда не ломалось? Да никак! Чудеса бывают только в сказках и платных мастер-классах.

Помните пару месяцев назад свалился процессинг одного крупного российского банкак? Даже один крупный российский банк с его многомиллионными бюджетами, почти полной редакцией Oracle 11g, наикрутешим аккаунтом в саппорте Oracle словил вполне тривиальную ошибку. Не срабатывает процесс создания резервной копии (check point) БД, переполняется лог транзакций, встаёт запись в базу. Точка.

Полностью защититься от беды нельзя, но можно значительно снизить риски. И рецепты тут давно известны — мониторинг с помощью того же Zabbix/Monit и резервирование!
На этом у меня всё. Вопросы?

Read more...