Рубрика «Блог компании Петер-Сервис» - 2

image

В крупных организациях часто возникает необходимость прикрутить к JIRA какой-либо дополнительный функционал, которого нет в стандартной поставке: автоматизацию, интеграцию с другими системами и прочие кастомизации. Зачастую это решается сторонними плагинами, в Atlassian Market их огромное количество. Но что делать, если подходящего плагина нет? Или он стоит 3000$, а вам нужна всего одна функция в нем? Очевидно, написать свой. Ещё один вариант для расширения — плагины, добавляющие возможность использовать свои скрипты в JIRA: ScriptRunner (Groovy), Jira Scripting Suite (SIL), JJupin (Jython).

В этой статье я расскажу о самом популярном и функциональном из них — ScriptRunner от Adaptavist. Читать полностью »

OneNote 2013, или Как привести дела в порядок - 1

«Возьми себя в руки, тряпка!» — сказал я себе, когда понял, что работа скоро доконает. Или она тебя, или ты её.

Дорога в тысячу ли начинается с первого шага.
Первым шагом стала книга Дэвида Аллена «Как привести дела в порядок: искусство продуктивности без стресса». Точки над i расставил курс Максима Дорофеева «Джедайская техника пустого инбокса, или Как доводить дела до конца».
 
Нельзя питать иллюзий, ступив на тропу войны. Проблемы не заставили себя долго ждать. Работа на компьютере требовала автоматизации. Дело стало за малым, поиск подходящего программного обеспечения для Getting Things Done (GTD).

Бесконечные пробы GTD-программ не принесли счастья. Комфортной работе мешало большое количество данных.
Не получалось связать задачи и данные внутри одной GTD-программы. Поток писем складировался в Outlook, документы и другие файлы на диске, часть информации на web ресурсах и так далее. Решая дела, приходилось тратить время на поиск связанных с ними данных. Возникали проблемы с синхронизацией информации на разных устройствах и многое другое.
 
Но кто ищет, тот всегда найдёт! Выходом из патовой ситуации оказался Microsoft OneNote 2013, который простыми настройками легко превратился в полноценный GTD-инструмент. Только такой подход позволил преодолеть все проблемы и ощутить комфорт от использования GTD.
Читать полностью »

juniper — можжевельник (англ.)

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

image

Содержание:

Часть 1: Знакомство
Часть 2: IPSec
Часть 3: Virtual Routers

В Juniper есть тип сущностей Routing Instance, предназначенный для манипуляций с трафиком (маршрутизации и инкапсуляции). RI позволяют «разделить» один роутер на несколько поменьше, при этом каждый instance будет обрабатывать трафик «по-своему», независимо от других и с разными возможностями. Это полезно для организации всевозможных VPN, когда нужно изолировать друг от друга нескольких клиентов и разрулить их по разным правилам. При этом информацией о VPN можно обмениваться с другими роутерами (например, при организации MPLS VPN).
Читать полностью »

How to prepare TCP - 1

Когда кому-то или чему-то становится плохо, то требуется нечто большее, чем просто констатация данного факта.
Читать полностью »

Oracle кластер умер, да здравствует кластеризация!

Здесь и далее имеется в виду cluster хранения данных, а не Oracle Real Application Custer

Проблематика

Большим информационным системам свойственно постоянное поступление различной информации, которая накапливается, обсчитывается и архивируется. Мы рассмотрим вариант структурированных данных, хранящихся на сервере RDBMS Oracle и в качестве примера возьмём таблицу, содержащую CDR записи (т.е. записи о вызовах) для абонентов оператора связи.
Данные о звонках поступают хаотично, т.е. не упорядоченно, как вы понимаете, по атрибутам абонентов. Все данные имеют свой жизненный цикл — оперативные, актуальные и архивные. Со временем частота обращений и требования по скорости доступа к данным меняются (т.е. падают). Т.о. записи годичной давности вполне можно хранить на медленных дисках, активные — на дисках с высокой скоростью доступа и без претензий на производительность операций записи, а вот вновь поступающим данным свойственно требование к максимально высокой скорости записи и чтения.
Читать полностью »

Все справедливо считают, что конструкция ORDER BY расходует ресурсы на проведение сортировки результата и в итоге мы должны получить результат несколько позже. Всегда ли это так?..
Читать полностью »

Как-то, анализируя дефект в разрабатываемом продукте, я наткнулся на архитектурную особенность менеджера памяти, который мы использовали. Дефект приводил к увеличению времени создания некоторых объектов. Особенность архитектуры заключалась в использовании паттерна Singleton при работе с менеджером памяти (далее X allocator). Схематично это выглядит так:

image
Рисунок 1 – Структурная схема работы X allocator

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

Не так давно мы пощупали немножко Juniper SRX, настроили его , и собрали отказоустойчивый кластер. Теперь начнем поднимать на нем «боевые» схемы, ради которых все и затевалось.
Например, соберем мысленно вот такую схему:
Настойка можжевельника: готовим Juniper SRX. Часть 2: IPSec

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

Читать полностью »

juniper — можжевельник (англ.)

Намедни в мои цепкие лапы попали два Juniper SRX 550. Попали не просто так, а для организации надежного ipsec и NAT-шлюза, а также OSPF-роутера. Ну а так как главное для нас — надежность, то именно с нее и начнем.

Для того, чтобы обеспечить отказоустойчивость сервисов, критично важные узлы обычно дублируют. Для ЦОДов это уже практически стандарт — N+N или хотя бы N+1. При этом устройства могут работать как независимо друг от друга, так и в кластере. Для обоих типов есть свои плюсы и минусы, но если нужен не просто роутинг/свитчинг, но нечто более «интеллектуальное» (например, те же NAT или IPSec), то без кластера тут точно не обойтись. Так что при плановом апгрейде в качестве замены Cisco 7201 рассматривались именно роутеры, способные работать в кластере. В связи с этим ASR 1k отправился лесом (как и ISR), ASA не рассматривалась (потому как готовить ее не умею), а VSS из Cat6503 — это уж слишком жирно и в плане цены, и в плане съедаемой электроэнергии.
Настойка можжевельника: готовим Juniper SRX. Часть 1
Герой нашего рассказа. (Здесь и далее — картинки с официального сайта Juniper)
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js