Мне было поручено найти комбинацию NoSQL (в данном случае, возможно, Neo4J) и SQL-Server - возможное решение возникшей у нас проблемы с производительностью.
Частью моего технического анализа является ремонтопригодность и стабильность платформы.
А это означает, что мне нужно найти способ правильно документировать и поддерживать редко используемые приложения (NoSQL) в сочетании с приложением, для которого у нас есть конкретные и строгие рекомендации (SQL-сервер).
В основном меня беспокоит то, что когда я просматриваю аналогичные настройки, сделанные в прошлом, одноразовые приложения, как правило, попадают в черный ящик ситуации, несмотря на то, что изначально были созданы собственными силами.
Те, которые не black boxes часто ложатся на плечи одинокого несчастного человека, который в конечном итоге проводит большую часть своего рабочего дня, поддерживая и обрабатывая некоторые доступ к базе данных устаревшая технология что никто не хочет трогать и очевидно критически важен.
Как вы, как удачливый системный администратор, отвечающий за установку и документирование этой платформы, убедитесь, что ваш чудовище отличная установка выдерживает испытание временем?
Как люди в более крупных корпорациях обычно обрабатывают одноразовые небольшие приложения, не привязывая навсегда свое имя к приложению?
Мой первый важный строительный блок - это план восстановления после катастрофы отличная установка в вопросе, т.е. пошаговый рецепт его восстановления с нуля и восстановления данных из последней резервной копии. Сюда входит список необходимых компонентов и их местонахождение, полная конфигурация и процедура полного восстановления данных приложения из последней резервной копии. Письмо и тестирование такой план откроет многие из самых зияющих дыр в операционной концепции, такие как данные, которые должны быть включены в резервную копию, но не включены, забытые зависимости или программное обеспечение, откуда никто не знает, откуда они.
Второй важный строительный блок - это руководство по эксплуатации, охватывающее задачи, возникающие при обычной эксплуатации. Это должно быть проверенотоже, в идеале, если администратор не знаком с отличная установка запускайте его по этому руководству в течение соответствующего периода времени, при этом обычный администратор в фоновом режиме делает заметки и будет доступен в случае возникновения чрезвычайных ситуаций.
Если отличная установка является критически важным, то его план аварийного восстановления, конечно же, будет включен в регулярные аварийные учения, санкционированные вашей СМИБ. Ежегодный отпуск обычного администратора - это естественная возможность для повторного тестирования руководства по эксплуатации. Так что оба периодически проверяются на актуальность.
Конечно, все это рушится, если не удается получить отличная установка классифицирован как критически важный для начала.
В общем, я делю свою документацию на несколько этапов. Первый этап - это разработка, которая ведется в хронологическом порядке и документирует все шаги, предпринятые для создания приложения. Я начинаю с четкого заявления о миссии, за которым следует список требований. Затем каждый шаг развития добавляется по мере его завершения. Я обнаружил, что видео, записывающее мои сеансы, является отличной поддержкой для памяти. Лично я использую Ticket System (в моем случае RT) для этого этапа документации.
Второй этап наступает после того, как приложение было протестировано и выпущено. Здесь я документирую установку (необходимое программное обеспечение, пакеты, среда). Все необходимое для воссоздания приложения. Последний этап - документирование процедур обслуживания. Документируются только особо сложные процедуры.
Наконец, я публикую второй и последний этап в вики. Кажется, что это большая работа, но когда документирование становится частью вашей повседневной работы, вы больше этого не замечаете. И, конечно же, шансы быть привязанными к развитию резко снижаются.
Надеюсь, это было полезно.